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

[Stephane Chazelas]

2019-07-06 07:19:50 -0500, Eric Blake:
[...]
> case $file in
>   -*) file=./$file ;;
> esac
> cat "$file"
> 
> for the same behavior for ALL files starting with '-' that are not to be
> confused with options, rather than just bypassing '-' for stdin.

Yes. It's more a problem with tools like grep that output the
file names, where 

$ grep -e foo -- *
file.txt:foo

with the work around gives a different output:

$ grep -e foo -- ./*
./file.txt:foo

It could be worse, see perl's -n/-p/<> for instance which cause
ACE vulnerabilities.

> > /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
> > instance).
> > 
> > It's unlikely people would use "cat -- -" and expect that "-" to
> > mean stdin, so it would be unlikely to break existing scripts.
> 
> Anyone knowing they want to cat "-" can just as easily directly write
> "cat ./-"; it's really only when you have an arbitrary user-supplied
> $file where you don't specifically know which file name you want to
> open, and where you want to ensure the user's input is not confused with
> an option or with stdin.

Yes, any time the arguments are not known in advance by the
script author like when they are the result of an expansion
(like pathname expansion, command substitution, parameter
expansion).

It's annoying that -- can be used to fix most of those problems,
but not -.

> 
> > (there's still the case of echo test | cat -- *.txt - or
> > cat -- "$file" - though)
> 
> "cat -- *.txt -" should concatenate all files ending in .txt plus stdin.
> If it cat's a file named "./-", then you've proven that this patch is a
> misfeature.

Yes, that's what I meant. Those are valid use cases that would
be broken. You'll notice I ended that argumentation with a "not
such a good idea after all".

[...]
> > 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
> > specially).
> 
> It is compliant. Guideline 13:
> "For utilities that use operands to represent files to be opened for
> either reading or writing, the '-' operand should be used to mean only
> standard input (or standard output when it is clear from context that an
> output file is being specified) or a file named -."
> 
> Touch is an output utility (it produces files, not consumes their
> contents), so the GNU Coreutils developers determined that it is clear
> from context that - can mean stdout (but you are correct that while it
> is permitted by POSIX, it is not mandated, and I don't know of other
> touch implementations that do the same).
[...]

touch doesn't "open" its file arguments for "reading" nor "writing".

That is not a valid interpretation, however much you want to
stretch it in my option.

It's more far fetched than saying

mv file -

Could be taken as moving "file" to the directory open on stdout
(as that's a case where mv opens the target directory file and
/writes/ a name in it).

-- 
Stephane