--- 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
signature.asc
Description: OpenPGP digital signature
--- End Message ---