GNU bug report logs - #33943
(omitted) ls directly uses filename as option parameter

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33943 in the body.
You can then email your comments to 33943 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: westlake <westlake2012 <at> videotron.ca>
To: bug-coreutils <at> gnu.org
Subject: (omitted) ls directly uses filename as option parameter
Date: Tue, 1 Jan 2019 00:46:02 -0500

Hi coreutils team,

 I have omitted that I recently downgraded my coreutils to doublecheck 
behaviour for ls, and noticed immediately the same behaviour was 
occuring,  .. however a period of time the behaviour is no longer 
exhibiting the same, I suppose I did not wait long enough for the new 
"ls" or whatever it is to come into effect...

but there's still oddities with ls, I guess it is the unprediction of 
"getopt".. and so I guess I should address any further concerns with the 
developers of getopt.

thanks

Message #10 received at 33943 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: westlake <westlake2012 <at> videotron.ca>
Cc: 33943 <at> debbugs.gnu.org
Subject: Re: bug#33943: (omitted) ls directly uses filename as option parameter
Date: Wed, 2 Jan 2019 21:06:21 -0700

tags 33943 notabug
close 33943
merge 33942
thanks

This message generated a new bug ticket.  I merged it with the
previous bug ticket.

westlake wrote:
>  I have omitted that I recently downgraded my coreutils to doublecheck
> behaviour for ls, and noticed immediately the same behaviour was occuring,

It was still occurring because this is not a new behavior of 'ls'.
This is the Unix has operated since the beginning.

It seems that you missed seeing Assaf's explanation of it.  Let me
repeat some of it.

> $touch 0 ./--a ./-a ./-_a ./--

> $ ls -lad  -* [^-]*

Here the first example nicely uses ./ in front of the problematic
characters.  But the second one did not have ./ there.  If it did then
there would be no problem.  But instead the "-*" above is trouble.
Don't do it!  Always put ./ in front of file globs (wildcards) like
that.  It should be:

  $ ls -lad  ./-* ./[^-]*

> .. however a period of time the behaviour is no longer exhibiting the same,

It was not a period of time.  It was the contents of the directory
upon which the commands were used.  It is data dependent.  It depends
upon the file names that exist.  If there are no file names that start
with a '-' then none will be mistaken for an option.  As you knew when
you created the test case using touch above.

> I suppose I did not wait long enough for the new "ls" or whatever it is to
> come into effect...

It is not a time issue.  It is only a matter of file glob wildcard
expansion as done by the command line shell.  Using 'echo' to see a
preview of the command will show this.

> but there's still oddities with ls, I guess it is the unprediction of
> "getopt".. and so I guess I should address any further concerns with the
> developers of getopt.

This is also not a getopt issue.  The best practice is to prefix all
wildcards with ./ such as ./*.txt so that the resulting text string
will not be confused with an option starting with a '-' even if the
file name starts with a '-' as the result will be "./-something" but
the resulting argument to ls will start with "./" instead of "-".

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.