mjhjmtu

POSIX and GNU have their syntax styles for options.
For all the commands that I have seen, they accept option-like inputs as command line arguments.

Is it uncommon for a program to accept option-like inputs from stdin (and therefore to use getopt to parse option-like stdin inputs) ? Something like:

$ ls -l 
-rw-rw-r-- 1 t t 31232 Jan 7 13:38 fetch.png
-rw-rw-r-- 1 t t 69401 Feb 6 14:35 proxy.png
$ myls
> -l 
-rw-rw-r-- 1 t t 31232 Jan 7 13:38 fetch.png
-rw-rw-r-- 1 t t 69401 Feb 6 14:35 proxy.png
> -l fetch.png
-rw-rw-r-- 1 t t 31232 Jan 7 13:38 fetch.png

Why is it uncommon for stdin inputs to have option-like inputs, while common for command line arguments?

From expressive power point of view (similar to regular languages vs context free languages), are nonoption like inputs and option like inputs equivalent?

Let's not emphasize on shell expansions, because we never expect (or need) something like shell expansion happen on stdin input (nonoption like).

Thanks.

Similar questions for nonoption like inputs: https://stackoverflow.com/questions/54584124/how-to-parse-non-option-command-line-arguments-and-stdin-inputs

tl;dr This is very similar to wanting to use ls in scripts (1, 2), quoting only when necessary, or crossing the streams (which is almost literally what this does, by using stdin for two completely orthogonal things). It is a bad idea.

There are several problems with such an approach:

1. Your tool will have to handle all of the expansions which a shell already handles for you:
   
   
   • brace expansion
   
   
   • tilde expansion
   
   
   • parameter and variable expansion
   
   
   • command substitution
   
   
   • arithmetic expansion
   
   
   • word splitting
   
   
   • filename expansion, including globbing as @StephenHarris points out
     
   
   


2. 
   If your tool does not handle any expansions (as you suggest, contrary to the example you've given which clearly has to do word splitting to not treat -l fetch.png as a single parameter) you will have to explain to developers at very great length why none of -l "$path", -l ~/Downloads and -l 'my files' do what they expect.


3. When your tool handles expansions differently from shells (which it will do, because shells handle expansions differently and nobody can afford to detect which shell you're running in and supporting all of them forever), you've just added a new syntax which needs to be learned, remembered and used by everyone using your tool.


4. Standard input is no longer just the tool input. Based on The Unix Philosophy, it can no longer trivially work together with other tools, because those other tools will have to do special things to pass input to your tool.


5. There is already a convention used by every major tool. Breaking convention in such a fundamental way would be a really bad idea in terms of usability.
   


6. 
   Mixing options and input cannot be done safely for arbitrary input, unless you go to the considerable extra trouble of encoding or escaping one of them.

Commands don't do that because many typically get their data from stdin. If stdin were a mix of options and data, things would be complicated (and dangerous).

It is very uncommon for Unix programs to accept command line options on stdin.

It would actually cause a change in behaviour because, in the Unix world, filename expansion ("globbing") is performed by the calling shell and not the application.

e.g. if you do ls *.c then the shell expands *.c into file1.c file2.c and so what is actually executed is ls file1.c file2.c.

If you had values on stdin then the program would be responsible for doing expansions.

So... not only is it not common, it's not really a good idea in the general case.

It's not unusual for programs to prompt for missing data

e.g.

#!/bin/bash

filename=$1

if [ -z "$filename" ]
then
 read -p Filename: filename
fi

But this isn't the same as taking command line options on stdin.