So while a prompt works great for your environment it rather sucks in a filter/pipe enviroment - the chaining concept breaks down fast if a program within the chain blocks to ask for some input that could have easily been supplied on the command line.

Toolbox, Filters and Piping are the key concepts at work here - the ability to chain together n number of programs to do what you want.

That is exactly what I was thinking. Take the classic Unix command line:

grep -i '^fred' $( ls f*.txt | fgrep -v 42 ) | sed -e's/Baltimore/Glen
+ Burnie/' | troff -mm -rN5 | lpr &
[download]

I count six different commands in that statement, and four take no arguments. The Unix philosophy of stringing together smaller utilities into a bigger tool encourage that sort of thing. DOS, which is still the basis of the Windows approach, has/had no such infrastructure to encourage this behavior. In fact, it probably discouraged it.

It's odd, but I see this affecting the approach to software that we take in my group at work vs another group that is all VB/Java. They mock and fear the command line, while those of us in the Unix world tend to think "Yeah, yeah, just because you don't understand it."

--
tbone1, YAPS (Yet Another Perl Schlub)
And remember, if he succeeds, so what.
- Chick McGee

I think it's a good option for installers, but really, just depends on what the program is supposed to be doing. If it can do only one thing, then it's best to hard code these things or have them in a config file. A standard Linux program should have something in /etc also.

If a user is going to the commandoline, then they usually know what they are doing, otherwise they would be using the GUI tools for installing things. If they forgot the switches, with half a brain, they would read the man page (if it has one).

It also creates a lot more work for the programmer and we're all lazy.

Gavin.

I'll produce error messages for missing but required input, but that's it. I want my programs to be used however the user needs it, including in shell scripts and cron jobs. I can't rely on any particular use.

Programs that insist on prompting for things are much more work to automate. You end up with entirely new languages like Expect (or the Perl equivalent of Expect) where you have to fool the computer into thinking you are a human, and you have to know the prompt strings and other interface bits. I typically want to spend as little time as possible with the computer, so I don't typically don't design programs that make me actually be there.

That being said, some programs might have some sort of flag to turn on "interactive mode" or some such. I have no problem with that sort of interaction as long as it isn't the only sort and as long as I don't have to work to turn it off. :)

When a program prompts for missing but required input, that's not going to break any shell scripts or cron jobs. It might cause mysterious hanging instead of simple death when used incorrectly, though.

---

Caution: Contents may have been coded under pressure.

I don't prompt for it, I issue an error message. That stuff ends up in a log file or email message, and people can discover what they need to change.

--
brian d foy <brian@stonehenge.com>

Installing Perl from source is a good example of this. A minimal example is:

#!/usr/bin/perl
use warnings;
use strict;

my $count = 0;

if( $ARGV[0] ){
   $count = $ARGV[0];
}else{
   print "Enter integer to count to, and press return\n";
   $count = <>;
   chomp $count;
}

for(0..$count){
  print "$_\n";
}
[download]

From the OP:

but whenever I write a small command line script [...] I always have it prompt for input if none is specified.

Period.


holli, /regexed monk/

In the Unix world, invoking the command without parameters generally makes it choose a set of well-documented defaults.

Prompting for parameters is also reasonable, but if you do that, please check that STDIN is a tty using the -t test.

The fact that many, many things behave this way, tends to make people implement other things in a compatible fashion... even if they are not something that is reading in files and/or writing out files.

Anyway, you ask why, and I think that's a pretty big part of why.

update (addition): I meant to point out: perl, itself, supports this mode of thinking very much so, by way of its -n and -p switches, and it's "diamond operator" <>, which all implicitly iterate over opening and reading from files in @ARGV or reading from STDIN if @ARGV is empty.

------------
:Wq
Not an editor command: Wq
[download]

It just annoys me when I have to prepare to run a program by going over the help message and slowly building the command to run.

This is just a matter of habituation (and maybe what sort of command-line shell you use). In your typical modern unix shell (bash, ksh, zsh and so on), hundreds of previously executed commands are kept in a command-history list; this list is kept in a file when you exit / log off / shut down, so that you can recall commands from yesterday or last Friday or after three reboots; there are simple, fast keystrokes for searching backwards in the history for each command containing a given string, and for editing command lines for re-execution; there are shortcut "placeholders" for using an argument from a previous command in your next command, and lots more features.

Then there's the common X-Windows environment, with 3-button mouse for quick and easy copy/paste within and across windows, and the "xterm" window for running a shell, with its ability to scroll back over hundreds of lines of prior shell i/o. Put all these together, and building command lines of arbitrary length/complexity is pretty quick work -- helluva lot faster than answering a series of questions that each ask for just ... one ... single ... parameter ... (and can only be answered manually).

In contrast, the typical "MS-DOS Prompt" shell is pretty painful to use on a repetitive or continuous basis, and there are several versions that are annoyingly different in the amount of command history/editing support they provide. The standard window used to run the shell is no help, with limited width/height/scroll-back and klunky mouse support (if any). Overall, using this sort of shell requires a lot more re-typing, and trying to use copy/paste operations involves lots of extra steps and higher risk of mistakes and wrist injury.

And if you're running a program that actually asks questions (one ... parameter ... at ... a ... time ...), God help you if you get to the fourth question and notice a mistake you made in answering the second one. (Start over, from the top -- retype everything -- repeat till your typing is perfect!)

Much better, I think, if the program will just say something to the effect of "Your last attempt at a command line was insufficient or incorrect; a proper command line should look like this: .... Please try again." Whenever possible, "option" args (e.g. "-v", "-log", etc) should be optional (meaning the program will do something sensible without them); it's okay to demand that there must be an arg for this or that purpose (input file, output file, or whatever), and if such args are missing, die and tell the user what's needed.

When a command dies for lack of proper usage, the good command-line user just hits the "up-arrow" key to recall the previous command, add or fix the arg(s) as needed, and hit "enter" to try again. Repeat until it comes out right -- but from one repetition to the next, you should never have to type the whole damn thing over again.