A Bit OT: Making the Command-Line Friendlier (DOS-Background, Long)

[Veli-Pekka Tätilä]

Hi Samuel,
Thanks for your reply. I'll snip pretty much and only comment some 
conclusions and other points you raise.

Samuel Thibault wrote:
> Ah, I thought would were criticizing the bare ls output. Well, yes,
Now that you got me going about this, I am, <grin>. I mean it lists multiple 
files on a line and most people cursor stuff in line chunks using console 
screen readres. So what I'll use in stead nearly always is ls -1. And I'd 
like to make that the default including piping it to the more or less 
commands. Well, does the alias syntax you showed me also work for zsh? 
Guess I should install it and read the manual.

> Just use the --time-style=locale option.  Again, the standard unix way is 
> to use the format above.
Is that the C-locale?

> 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.
I agree most of the time. SOmtimes it seems accessibility and usability 
conflict with each other, and in those cases usability is likely to win. For 
example, separating by commas would be easier to parse in once head with 
speech or in most scripting languages, but most people will find spaces look 
nicer.

> Please don't consider that programmers are necessarily lazy.
They are sometimes. One such thing are error messages. I sometimes write 
scripts in which error handling is the first thought that comes to mind 
stuff like:

open my $file, '>', $name or die "cannot open $name because $!.\n";

and I'm sure I'm not the only one. The thing is:
It is true that the file canot be opened but from the user's point of view 
it might very well be a save as operation. IN which case you should talk 
about saving as or writing a file as opposed to opening it. GUI people will 
think open refers to the open dialog.

> So just explain them how things should rather be done,
That's a good basic strategy I've used in Windows. The advantage in there is 
that tab order and focus handling are expected to work. If they don't, it is 
not exclusively an accessibility  issue and fixing it is easy to justify. 
The same thing with Gnome.

> think twice before typing enter
Hmmm, I still don't like this. I mean, people are bound to make mistakes and 
I often do something and think afterwords. That's why, despite being a GUI 
power-user, I find the Bin extremely useful. In the GUI, it doesn't confirm 
deletion but if I notice that somethihng went wrong, ctrl+z brings it back. 
I suppose this will also work with Gnome, seeing how thoroughly they've 
cloned WIndows.

> (that's why there is usually no "undelete" command in Unix, btw).
And no decent script to implement a recycle bin, right? To be real affective 
I suppose one would have to hook into the underlying sys calls to have this 
work in apps in addition to just shells.

>> Which one would be good as far as confirmations go?
> zsh is fine.
You mentioned later on that staying in the shell is considered almost 
programming  and I said I don't like to do that in casual file management 
but do like Perl, actually. So if CSH has C-like syntax and ZSH includes 
Perlish regular expressions, is there a Perl shell? I think I read about 
some such project but they aren't actively being developed.

> Unix in general has the "read documentation, thenwork" philosophy, you 
> can't compete that.
Yeah, I've noticed. And often it means read the whole documentation, 
experiment, read it again and then succesfully use the command. This is 
totally unlike Unix but I've been toying around with the idea of a shell 
that was as polite as a Mac and had friendly pseudo object-oriented 
commands and named parameters ala Python. Something that's aimed at people 
who can just sit down at a terminal, type  in help and be using the thing in 
minutes. Not as powerful as Unix would be, but you could certainly make such 
a shell much more powerful than the puny command.com. I suppose fish is 
currently about the friendliest shell there is. Unix users tend to be 
power-users and those who prefer the GUI try to avoid the command-line but 
will ultimately fail. This is one of the big disappointments to me. You need 
text config files and the shell as soon as something does not have a 
front-end or is not thought to be important enough to be configured by the 
average user. A major annoyance is that this includes Gnome themes, which 
are important for low-vision folks for accessibility's sake.

> Manual pages are reference documentation (
Arrgh, that's quite bad really. Fortunately GUI apps have a sounder 
philosophy in this. No-one expects you to absolutely master an app based on 
a pure menu reference, for example. I know the comparison is a bit unfair 
but needless to say, I really don't liek this philosophy.

Fortunately, the Unix man pages aren't exactly reference like, either. They 
are often tens of screenfuls and go into quite a lot of detail only they 
aren't quite thorough enough for new users,

> introduction documentation (info pages, books and teachers are there
Howabout Wikis? It would be great if ordinary users could instruct each 
other in using commands. You could then add analogies to DOS, Mac, common 
programming languages including Qbasic etc...

> unfortunately) few people know. Type info coreutils for instance, for
Thanks, will try that. HOW widely are these available?

>> 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>
> <added> because as it is currently, this sentence is fine to me...
> yes, documentation needs to be done by not-so-technical people.
Quite right.  I could actually find loads and loads of other similar 
examples. This might not match the Unix philosophy but when wearing my user 
hat, I don't care how something works as long as it works. Dir is documented 
like this so it says:

/S Displays files in specified directory and all subdirectories.

That's all you need to know. Unix man pages go further and state that:

-R, --recursive list subdirectories recursively

Which makes sense for programmers, computer science folk and mathematicians 
but leaves the rest wondering what they might have missed. I find the DOS 
version clearer. I mean how many end users need to know whether the 
algorithm is recursive or not? You hardly ever run out of stack space 
anyway. None of the GUI tools I've seen use the term recursive, and I 
consider this a good thing.

> Mmm, I can't remember exactly which one this was, maybe mc (midnight
> commander) and other such tools may fit your needs?
I tried MC a couple of days back and my WIndows screen reader didn't track 
the focus in the terminal emulator. It is probably quite a complex app for 
console screen readers. Are anyone else having better luck say with Yasr or 
Speakup?

The Norton tree is simply a scrolling ASCII tree of directories in which you 
can navigate with arrows and go to a dir with enter.

> ":)" is indeed probably not quite well read by speech synthesis,
Colon right paren. Yup that's why I use pseudo HTMl tags myself. But this 
would be bad as a global abbreviation. Some programming construct is 
probably using it.

-- 
With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/