-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 (The post is removed due to no response and downvotes. but still accessible if you have sufficient reputations)

Tim
  • 101,790
  • 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 07 '19 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 07 '19 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 08 '19 at 00: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 08 '19 at 01:16
  • @炸鱼薯条 What do you mean by " it just loose the ability of fully automation using script"? – Tim Feb 08 '19 at 01:17
  • parted and adduser do provide such functionality, but they can't be used in script like that – 炸鱼薯条德里克 Feb 08 '19 at 01:23
  • @炸 What benefits come from parted and adduser accepting option inputs from stdin? Can't they use non-option like inputs in place of option like inputs? Do non-option like inputs in place of option like inputs have the same expressive power (formal language concept)? – Tim Feb 08 '19 at 01:31
  • unattended operation is contradict with interaction – 炸鱼薯条德里克 Feb 08 '19 at 01:36
  • @炸 what do you mean by "unattended operation is contradict with interaction"? – Tim Feb 08 '19 at 01:38
  • Try to google "interaction" and "unattended operation". – 炸鱼薯条德里克 Feb 08 '19 at 04:04

3 Answers3

5

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.
l0b0
  • 51,350
  • Thanks. Pardon me that I perhaps haven't come up a good title or described my question clearly – Tim Feb 08 '19 at 00: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 08 '19 at 01: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 08 '19 at 02: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 08 '19 at 04:01
3

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

xenoid
  • 8,888
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.

Stephen Harris
  • 44,540