1

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

  • No utility that I can recall does that. How would it know how long to block waiting for additional inputs from stdin? – Andrew Henle Feb 7 at 23:52
  • Is the need to "know how long to block waiting for additional inputs from stdin" just for option like inputs, or also for non-option inputs? Your comment seems to imply it is just for option like inputs, which I am not sure of. – Tim Feb 7 at 23:54
  • 1
    FYI the phrasing "Is it not a convention that ..." would usually be suggesting that you think it is a convention, but I don't think you do mean that here. You might like to rephrase the title to avoid confusion. (Unless you do mean it that way, then never mind) – Michael Homer Feb 8 at 0:06
  • You're asking for a interactive tool, which is not very useful because of Unix tradition, it just loose the ability of fully automation using script – 炸鱼薯条德里克 Feb 8 at 1:16
  • @炸鱼薯条 What do you mean by " it just loose the ability of fully automation using script"? – Tim Feb 8 at 1:17
3

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.
  • Thanks. Pardon me that I perhaps haven't come up a good title or described my question clearly – Tim Feb 8 at 0:49
  • 1
    Even worse; different shells evaluate all those expansions in different ways, so if the application does it then you've effectively added a new syntax variant to deal with! – Stephen Harris Feb 8 at 1:45
  • What do you mean by "Your tool no longer takes its input on standard input"? Both option like inputs and non-option like inputs can come from stdin. – Tim Feb 8 at 2:25
  • Answer has been edited. @Tim If options and data are both from the same file, then the input file format is only known by your tool, then other tools can't produce the file content your tool need. Also, recording options(consideted to be kind of code) together with data is one of examples of bad programming practice since maintaining code is much harder than just data. If you have programming experience, you will easily understand that. – 炸鱼薯条德里克 Feb 8 at 4:01
2

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).

  • Thanks. How complicated (and dangerous)? – Tim Feb 8 at 0:50
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.