new | ask | show | jobs
kazinator 8 hours ago  [ - ]

  zsh% < data > /dev/null && echo READABLE   # <- fixes it, sorta
Maybe zsh still reads the entire file and copies it to /dev/null, which would be a severe performance problem for large files.

The colon by itself, without the subprocess, also prevents the dumping to stdout:

  zsh% : < data && echo READABLE
However, with the subprocess parentheses, we can redirect the nonexistence diagnostic to /dev/null, which I don't see mentioned or exemplified in the article:

  zsh% : < nonexistent 2> /dev/null && echo READABLE
  zsh: no such file or directory: nonexistent
  zsh% (: < nonexistent) 2> /dev/null && echo READABLE
The normal way of testing whether something exists and is readable that you would actually use in production script looks more like this:

  $ test -r file && echo YES
  $ [ -r file ] && echo YES
so we are talking about obfuscated coding.

I would say that "if you want something everyone can use", the -r test would be the first candidate.

BTW, why not bring up the strawman of tcsh?

  tcsh% < nonexistent && echo READABLE
  Invalid null command.
  tcsh% : < nonexistent && echo READABLE
  nonexistent: No such file or directory.
Yes, if we want an obfuscated readability test which works literally in any shell that is currently still in deployment in systems that permit new scripts to be installed and run, it looks like do need that colon.

However, fish doesn't like &&:

  fish> < nonexistent && echo yes
  fish: Expected a command, but instead found a redirection
  fish> : < nonexistent && echo yes
  fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
  : < nonexistent && echo yes
                  ^
Does it support test -r?

  fish> test -r nonexistent
  fish> test -r nonexistent; and echo yes
  fish> test -r /etc/hosts; and echo yes
  yes
Not parentheses though:

  fish> ( test -r /etc/hosts ); and echo yes
  fish: Illegal command name “( test -r /etc/hosts )”
We clearly have to restrict the idea of what "everyone can use" to POSIX-like shells; there is no getting around shell differences absolutely, other than for perhaps trivial command invocations.
refp 6 hours ago  [ - ]

I think you should take a deep breath and read this updated FAQ:

https://refp.se/articles/your-shell-and-the-magic-colon#why-...

I am not asking anyone to put this in production, it is a tongue-in-cheek/cute way of explaining/showing what the null-command _can_ do, not what it _must_ do.

No, any distro that stopped shipping entities mentioned to use only null-command variants.. well, I'd save whatever your end goal is to a meeting with them.

Just enjoy the article for what it is — a piece of trivia.

Best Regards, Filip Roséen - refp

kazinator 6 hours ago  [ - ]

I understand; it's just "here are these cool, obscure things you can do with the colon". I had no idea it was supposed to be "here are these cool, obscure things yuo can do with the colon, carefully coded to work on numerous POSIX-like shells that are in widespread use.

To me, it's "cool" that you can just do "< test-file && echo exists", on a shell whose developers haven't decided to imbue a whole bunch of new requirements into redirection. It's completely legit to note that the existence test is not coming from the : command, but from redirections, and redirections can be set up without a command. The : is only there to work around shell quirks.

For decades, I used "> file" to truncate files to zero length, never with a colon command; the example makes it look as if the colon is required in order for the command line to be valid and for the effect to take place.

BTW I noticed that zsh not only does the cat-like dumping to stdout in non-interactive mode, but it also does the redirection to the pager!!! So if you drop that test into a non-interactive script, and it finds an existing file, if that script is run in a terminal session, it will pause for input.