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