emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#24599: closed (Cannot process files named -)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#24599: closed (Cannot process files named -)
Date: Mon, 03 Oct 2016 19:40:02 +0000

Your message dated Mon, 3 Oct 2016 14:39:06 -0500
with message-id <address@hidden>
and subject line Re: bug#24599: Cannot process files named -
has caused the debbugs.gnu.org bug report #24599,
regarding Cannot process files named -
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
24599: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24599
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Cannot process files named - Date: Mon, 3 Oct 2016 19:12:59 +0100
Good afternoon,

As I was trying to reimplement the coreutils in Haskell (for fun :D), I
noticed that many commands (such as "cat -- -") will disregard the --
and try to read the stdin.

I initially thought this was not a bug (found no report about this in
these mailing lists while searching for «file named ""-""»), but it
works as expected with vi ("vi -" tries to read stdin, "vi -- -" edits
the file named -).

Looking through the source code (of "cat" in this case, because it's
simpler), "-" is not taken to be an option (it's not possible with the
way Getopt works in Haskell, seems it's not possible in C either - is
adding "{NULL, no_argument, NULL, '\0'}" to long_options possible? I
don't really know C...). But it can be worked around, here (lines 663 to
669):

   if (STREQ (infile, "-"))   // should add "&& noopt_was_passed"
     {
       have_read_stdin = true;
       input_desc = STDIN_FILENO;
       if ((file_open_mode & O_BINARY) && ! isatty (STDIN_FILENO))
         xfreopen (NULL, "rb", stdin);
     }

an extra check for "--" could be added (in Haskell this would require
checking *before* the arguments were passed to getopt, probably the same
applies to C).

I've seen this behaviour in "cut" as well, and other programs, as this
seems to show:
  $ pwd
 /home/jmcf125/abs/core/coreutils/src/coreutils-8.25/src
  $ grep 'if (STREQ.*"-")' -R . | cut -f1 -d' ' | uniq | sed -e
's#\./##' -e 's#:##' | tr '\n' ' '
 stat.c cut.c tail.c shred.c unexpand.c od.c nl.c sort.c touch.c
 date.c fold.c expand.c pr.c wc.c fmt.c base64.c cksum.c cat.c paste.c 

Hoping you can reply soon (not subscribed),
João Miguel



--- End Message ---
--- Begin Message --- Subject: Re: bug#24599: Cannot process files named - Date: Mon, 3 Oct 2016 14:39:06 -0500 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
tag 24599 notabug
thanks

On 10/03/2016 01:12 PM, João Miguel wrote:
> Good afternoon,
> 
> As I was trying to reimplement the coreutils in Haskell (for fun :D), I
> noticed that many commands (such as "cat -- -") will disregard the --
> and try to read the stdin.

Generally because that is the behavior required by POSIX.

> 
> I initially thought this was not a bug (found no report about this in
> these mailing lists while searching for «file named ""-""»), but it
> works as expected with vi ("vi -" tries to read stdin, "vi -- -" edits
> the file named -).

Arguably a bug in vi.  But this is not the vi list, so hard to make that
call here.

If you WANT to read a file named '-' in the current directory, you can
ALWAYS use './-'.  Therefore, special-casing whether a lone '-' appeared
before or after the '--' end-of-options designator, when getopt() does
NOT treat plain "-" as an option in the first place, is not worth the
hassle.

I have no idea if the Haskell mapping of getopt() functionality makes
this easier or harder for your task at hand, but I can state that the
behavior in coreutils is intentional and not a bug.

> Hoping you can reply soon (not subscribed),

It's list policy to reply-to-all, precisely so you do not have to subscribe.

At any rate, since the behavior is intentional, and complies with POSIX,
I'm marking this as not a bug.  However, feel free to add further
comments or questions to the thread.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]