[Top][All Lists]

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

Re: [PATCH] cat: open any file name after "--"

From: Stephane Chazelas
Subject: Re: [PATCH] cat: open any file name after "--"
Date: Sat, 6 Jul 2019 10:14:25 +0100
User-agent: NeoMutt/20171215

2019-07-05 23:31:06 -0500, Eric Blake:
> Sorry, but this patch violates POSIX.
> "If a file is '-', the cat utility shall read from the standard input at
> that point in the sequence."

But coreutils could do that when not under $POSIXLY_CORRECT, as
that's admitedly a design flaw, and is quite annoying to have to

case $file in
 (-) file=./-;;
cat -- "$file"

to work around it.

/dev/stdin could be seen as a fix to that misdesign, but not on
Linux or Cygwin (where for instance cat /dev/stdin /dev/stdin
does not work the same as cat - - unless stdin is a pipe for

It's unlikely people would use "cat -- -" and expect that "-" to
mean stdin, so it would be unlikely to break existing scripts.
(there's still the case of echo test | cat -- *.txt - or
cat -- "$file" - though)

But then, the same would have to be done for all GNU utilities
for consistency. But then there are utilities like paste, join,
comm where that would not be desirable, so probably not a good
idea in the end (see also how paste - - doesn't work the same as
paste /dev/stdin /dev/stdin even on systems other than

Note that gawk already does it in

gawk -E file.awk "$file"

Where using -E (as opposed to -f) fixes that problem and the one
about "var=value.txt" being treated as a variable assignment and
that other options are still processed by awk.

> If you wish to cat a file named '-' in the current directory, spell it
> './-' or use an absolute path to that file.  That's true of all command
> line utilities that treat '-' as stdin (not just cat).

Or in a shell, use:

cat < "$file"


cat - < "$file"

(but not cat -- - < "$file" ;-)

To concatenate arbitrary files, ironically you can do:

cat /dev/stdin /dev/fd/3 < "$file1" 3< "$file2"

Which also has the benefit (or not) of not outputting anything
if any of the files can't be opened.

2019-07-05 23:48:17 -0500, Eric Blake:
> For more fun, go figure out why:
> grep - - --
> grep [---]
> behave the same, regardless of whether you have a file named '-' in your
> current working directory (unless you use shopt -s failglob).  And the
> rule on using ./- for a file in the current directory also applies to
> touch, except there '-' means stdout instead of stdin.

Only with GNU grep or compatible and when $POSIXLY_CORRECT is
not in the environment. That's another misfeature IMO, but this
time introduced by GNU and not *allowed* by POSIX.

in "grep - - --", while for grep POSIX leaves it undefined
whether "-" is treated as stdin or not, that "--" is required to
be a file argument since it comes after a non-option argument.
So that would likely report an error about a missing "--" file.

That means that while:

grep - *.txt

is fine for POSIX compliant grep implementations, in GNU grep,
you need:

grep -- - *.txt


grep -e - -- *.txt


grep [---]

With bash, beside failglob, nullglob would also change the
behaviour. Also, the behaviour of ranges is unspecified in POSIX
outside of the POSIX locale. It could match (for both glob and
grep RE) collating elements that are /equivalent/ to - for

That behaviour of GNU touch wrt touch - is not POSIX compliant
AFAICT (though that's another case where /dev/stdout wouldn't
work unless "touch" itself treated a "/dev/stdout" argument


reply via email to

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