Veli-Pekka Tätilä, le Mon 09 Oct 2006 18:57:56 +0300, a écrit : > Samuel Thibault wrote: > >> LS output is very speech unfriendly, > > What do you mean? Because it speaks all file names? > WIth this in mind the ls -l ordering and formatting is quite bad. For > example: > > -rw-r--r-- 1 vtatila vtatila 17719 2006-02-16 13:10 License.txt
Ah, I though would were criticizing the bare ls output. Well, yes, Unix' ls -l has been giving the file name at the far right for ages, but you can ask for an option which would put it at the far left. > Lastly, although I chose the FInnish time zone and keyboard the locale isnt > quite right. The date is:' > > 2006-02-16 > > Which is bad as the year changes least often yet is the first thing you'll > have to listen to. To follow the principle of most important and or > surprising info first, I'd rather seee the dates in the order: dd.mm yy. Just use the --time-style=locale option. Again, the standard unix way is to use the format above. > On the other hand, MOst programmers will never even stop to think of how > their textual output sounds with speech as they don't need it. The problem is _not_ to have programmers start thinking about this, but to provide them information so that they can put themselves in your place. Please don't consider that programmers are necessarily lazy. They are just _unable_ to know how they should do things. They have _never_ seen a braille device, and have _never_ heard a speech synthesizer, and even less know how all this may work. So just explain them how things should rather be done, and they'll implement that. > Anyway, I'd appreciate any reformatting scripts people have done to > address the ls -l problem so as to not re-invent the wheel. I'm not aware of any. I'd say you should ask coreutils' maintainer to add an option for choosing the exact format. Or explain him a format that would be suitable for speech. > >> silence on success feels disconcerting, > > Isn't the prompt spoken ? > Nah, I mean the general Unix philosophy of not printing anything but a new > line if everything went OK. That's what all Unix users are used to. You can't compete that. > > when you use commands in a shell script, you don't want to have all > > confirmations printed by default. > But aren't you using the system mostly interactively? Not really. I think twice before typing enter, and that's fine (that's why there is usually no "undelete" command in Unix, btw). > Another option is being verbose and interactive by default and > having switches for turning them off typically -q and -y. Or being > interactive if the input comes from the user's keyboard. Yes, this is what some distributions do by default, and I don't like it <smile> But you can do this for yourself. > > you can use another shell than bash > Which one would be good as far as confirmations go? zsh is fine. > >> That is more hand holding, > > What do you mean ? > Assuming that the user is not a programmer and might be new to the system. > LInux is not very discoverable. You just canot guess that cat is short for > concatenate or that chmod changes rights. Indeed, you need an introduction manual for this. There are plenty of them in libraries. Unix in general has the "read documentation, then work" philosophy, you can't compete that. > Another classic example of where one would need more help are the manual > pages. SOmeone once said that docs written by software engineers tend to be > the author's proud and often highly technical account of what's going on in > a system and I feel just like that about the Unix manual pages. Why aren't > common Unix terms explained or hyperlinked in the man pages? Because that's not how documentation works. Manual pages are reference documentation (i.e. "oh, how was this option named btw?"), not introduction documentation (info pages, books and teachers are there for this). Note: yes, there also are the info pages, that apparently (and unfortunately) few people know. Type info coreutils for instance, for having an introduction to coreutils tools. > This sentence says three or four things in a long, hard-to-understand style > with two sets of parentheses in it. Well, you're welcome to rephrase it and submit it <smile> > Shouldn't the manual pages be for people who don't know how to use the > apps? Historically speaking, no. Now, if you want this to change, just work on it ;) > > alias cp='cp -v' > Just out of curiosity, can you still override that verbose flag on the > command-line if the need be? Apparently unfortunately no. But you can skip the alias by using \cp foo bar > Another problem of mine, is that when I'm doing basic file operations > I don't think of it as programming and don't like to deal with > complexity and programmer terms. Well, the shell is indeed from the ground considered as a programming language... > On a side note, Is there anything like the NOrton Tree for LInux? That's one > of the first impressive DOS utils I fondly recall as a kid. Mmm, I can't remember exactly which one this was, maybe mc (midnight commander) and other such tools may fit your needs? > do you know any console editors which would have both a menu bar > (like Edit), and also hotkeys that are familiar to Windows or Gnome > users? The closest vague matches I've found so far are Nano and Joe. Yes. > > Note however: don't say "printing `cannot stat foo' sucks !, > Won't do that, thanks for reminding me, <smile>. Ah, that reminds me: ":)" is indeed probably not quite well read by speech synthesis, but most people will always use it. Solutions are needed for this too... Samuel -- Ubuntu-accessibility mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
