dir name "0" not safe with Cwd.pm

[p5pRT]

Migrated from rt.perl.org#3906 (status was 'resolved')

Searchable as RT3906$

[p5pRT]

From wolfgang.laun@alcatel.at

Created by Wolfgang.Laun@alcatel.at

use Cwd qw{ chdir getcwd fast_abs_path }; print "subdir ./0 exists\n" if -d '0'; print "./0 abs path=" . fast_abs_path( '0' ) . "\n"; chdir( '0' ); print "wd now​:" . getcwd() . "\n";

Output​:

subdir ./0 exists ./0 abs path=/home/laune/ppt/make wd now​:/home/laune

These errors come from the lines in Cwd.pm​:

sub fast_abs_path {   my $cwd = getcwd();   my $path = shift || '.';   ^^^^^^^^ ... sub chdir {   my $newdir = shift || ''; # allow for no arg (chdir to HOME dir)   ^^^^^^^^

Perl Info

``` Flags: category=library severity=critical Site configuration information for perl v5.6.0: Configured by root at Sat Mar 25 17:46:37 CET 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.12-20, archname=i586-linux uname='linux localhost.localdomain 2.2.12-20 #1 mon sep 27 10:25:54 edt 1999 i586 unknown ' config_args='-de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-fno-strict-aliasing -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=/lib/libc-2.1.2.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: @INC for perl v5.6.0: /usr/local/lib/perl5/5.6.0/i586-linux /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/i586-linux /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl/5.5.670/i586-linux /usr/local/lib/perl5/site_perl/5.5.670 /usr/local/lib/perl5/site_perl . Environment for perl v5.6.0: HOME=/home/laune LANG=en LANGUAGE (unset) LC_ALL=en_US LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:/home/laune/bin:/usr/X11R6/bin:/home/laune/bin PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @jhi

These errors come from the lines in Cwd.pm​:

sub fast_abs_path { my $cwd = getcwd(); my $path = shift || '.'; ^^^^^^^^ ... sub chdir { my $newdir = shift || ''; # allow for no arg (chdir to HOME dir) ^^^^^^^^

Thanks for the bug report.

(Sidenote​: there are undoubtedly more of these. The oh-so convenient true-false rule of Perl cannot unfortunately be extended to file/directory names. Saying 'but no one will ever use "0" as a f/d name' is not that different from saying 'but no one will ever try to follow the null pointer' or 'but no one will ever divide by zero'...if the domain/range of a variable contains illegal values or other discontinuities\, someone *will* some day try to use them.)

[p5pRT]

From [Unknown Contact. See original ticket]

These errors come from the lines in Cwd.pm​:

sub fast_abs_path { my $cwd = getcwd(); my $path = shift || '.'; ^^^^^^^^ ... sub chdir { my $newdir = shift || ''; # allow for no arg (chdir to HOME dir) ^^^^^^^^

Thanks for the bug report.

(Sidenote​: there are undoubtedly more of these. The oh-so convenient true-false rule of Perl cannot unfortunately be extended to file/directory names. Saying 'but no one will ever use "0" as a f/d name' is not that different from saying 'but no one will ever try to follow the null pointer' or 'but no one will ever divide by zero'...if the domain/range of a variable contains illegal values or other discontinuities\, someone *will* some day try to use them.)

Just because you can have pathnames starting with "-" doesn't mean you can't remove then with /bin/rm either. :-) That's why people pass them as "./-"\, for example.

However\, your point is taken​: a *library* function oughtn't do that\, and should accept any string. C\<@​_ ? shift : "."> is a more normal idiom there.

--tom

[p5pRT]

From @AlanBurlison

Tom Christiansen wrote​:

Just because you can have pathnames starting with "-" doesn't mean you can't remove then with /bin/rm either. :-) That's why people pass them as "./-"\, for example.

Tsk tsk.

$ touch ./- $ ls - $ /bin/rm -- - $ ls $

:-)

Alan Burlison

[p5pRT]

From [Unknown Contact. See original ticket]

Just because you can have pathnames starting with "-" doesn't mean you can't remove then with /bin/rm either. :-) That's why people pass them as "./-"\, for example.

Tsk tsk.

$ touch ./- $ ls - $ /bin/rm -- - $ ls $

Ah\, but "./-" doesn't require special-purpose aurgment parsing\, which is why it's the more general solution.

--tom

[p5pRT]

From @AlanBurlison

Tom Christiansen wrote​:

Ah\, but "./-" doesn't require special-purpose aurgment parsing\, which is why it's the more general solution.

From the getopts(3C) manpage​:

  The getopt() function returns the next option letter in argv   that matches a letter in optstring. It supports all the   rules of the command syntax standard (see intro(1)). Since   all new commands are intended to adhere to the command syn-   tax standard\, they should use getopts(1)\, getopt(3C) or   getsubopt(3C) to parse positional parameters and check for   options that are legal for that command. ...   The special option   "--" (two hyphens) may be used to delimit the end of the   options; when it is encountered\, EOF is returned and "--"'   is skipped. This is useful in delimiting non-option argu-   ments that begin with "-" (hyphen).

So any properly written command will already have this behaviour.

Yes\, I'm just being unnecessarily pedantic.

But it *is* fun to be a pedant sometimes ;-)

[p5pRT]

From [Unknown Contact. See original ticket]

So any properly written command will already have this behaviour.

It's difficult to imagine that these folks seriously imagine that *all* "proper" programs *shall* use the libc getopts functions. After all\, not all programs are written in C! And even if they were\, it's not like you can are forbidden from making an a.out without linking to getopts\, which is the only way to make that so.

Personally\, I might be more apt to use getopts in a C program than a Perl one\, where it's so easy not to. But historically\, I've never bothered. Too easy to avoid.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

On Mon\, 28 Aug 2000\, Jarkko Hietaniemi wrote​:

These errors come from the lines in Cwd.pm​:

sub fast_abs_path { my $cwd = getcwd(); my $path = shift || '.'; ^^^^^^^^ ... sub chdir { my $newdir = shift || ''; # allow for no arg (chdir to HOME dir) ^^^^^^^^

Thanks for the bug report.

(Sidenote​: there are undoubtedly more of these. The oh-so convenient true-false rule of Perl cannot unfortunately be extended to file/directory names. Saying 'but no one will ever use "0" as a f/d name' is not that different from saying 'but no one will ever try to follow the null pointer' or 'but no one will ever divide by zero'...if the domain/range of a variable contains illegal values or other discontinuities\, someone *will* some day try to use them.)

shift ?? '';

*duck* :-)

[p5pRT]

From @AlanBurlison

Tom Christiansen wrote​:

So any properly written command will already have this behaviour.

It's difficult to imagine that these folks seriously imagine that *all* "proper" programs *shall* use the libc getopts functions. After all\, not all programs are written in C! And even if they were\, it's not like you can are forbidden from making an a.out without linking to getopts\, which is the only way to make that so.

It is a POSIX thing. If you don't have the behaviour documented in getopt(3C) and intro(1)\, Rule 10 you aren't POSIX compliant. Watch out - your willy will drop off if you aren't POSIX compliant. You of all people should know that already.

[p5pRT]

From The RT System itself

Other like bugs (assuming that a file/dirname cannot be "0") might exist in the core modules.