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 [EMAIL PROTECTED], 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 -- Ubuntu-accessibility mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
