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

[Veli-Pekka Tätilä]

Samuel Thibault wrote:
>> LS output is very speech unfriendly,
> What do you mean? Because it speaks all file names?
Not really, let me elaborate. Most screen readres have a browse mode for 
moving around the screen independently of the cursor. In the typical 
scenario you start examining screen reader output by enabling this browsing 
mode and then cursoring around the screen in line chunks. Speech is a linear 
medium with no easy means of skipping over columns of data, and it reads all 
columns from left to right. 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

The rights are read first and the file name is the right most column. 
Because of this one has to either cursor by word to reach the file name or 
wait for the whole line to be read. The file name should be left most to 
give the rest of the data, such as the rights, much more significance and 
context. ls doesn't let you modify the column order at all. I'll probably 
process the output with Perl if I must.

For ideal speech use, columns should be comma or colon separated as they 
produce a pause in speech within most synths. Spaces do not add any pauses, 
and thus you get subsequent columns run together in a very fast and 
confusing speech stream.

Further more, the permissions are clear visually or using Braille but not 
with speech:

-rw-r--r--

dash are double you dash are dash dash and so on. The words read, write and 
execute might convey their meaning much better or simply using the mode in 
octal i.e: 644.

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.

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. Anyway, I'd 
appreciate any reformatting scripts people have done to address the ls -l 
problem so as to not re-invent the wheel.

>> 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. FOr example, if you messed up with a copy and 
didn't have the verbose flag on, you would have no easy way to see or undo 
what was actually copied and where. This is one of the Nielsen heuristics in 
the GUI-world, visibility of system status. Here's the full list:

http://www.useit.com/papers/heuristic/heuristic_list.html

Of course, command-languages and power users are another story. ONe has to 
consider the context of use; you mentioned scripting already. The Unix 
history of programmer types and dumb terminals does affect matters, too.

> 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? 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.

> you can use another shell than bash
Which one would be good as far as confirmations go? I've tried Fish but some 
of its coloring or special chars apparently trips up my emulated VT100.

> problem is that programmers are programmers.  But you can report this
Quite right, I think I might consider reporting, good to know the option is 
available.

>> 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. Again I do realize these names are 
well established and short to type. I'd rather take long and discoverable 
names Java-style, which could then be predictably shortened based on a 
unique string prefix. The Perl utility PPM supports this you can type desc 
or just d in stead of describe.

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? That would make 
the docs more readable for those new to Unix. For example:

GNU find searches the directory tree rooted at each given file  name  by 
evaluating  the given  expression  from left to right, according to the 
rules of precedence (see section OPERATORS), until the outcome  is  known 
(the  left hand  side  is  false  for and operations, true for or), at which 
point find moves on to the next file name.

This sentence says three or four things in a long, hard-to-understand style 
with two sets of parentheses in it. What is essential to me as a user is 
that: find selects files or folders based on a condition and runs one or 
more actions for each selected item, letting you apply the same command for 
a number of items. SOmetimes terse formalism has its place but find isn't a 
good example of that. The K&R book and many perldoc pages are, if you ask 
me.

I think all this talk about Boolean logic, operators and precedence is 
mentioned too early. It is programmer terminology, too. Supposing one 
doesn't know programming, which I do, where do you find a definition of what 
is an operand or what precedence means? Shouldn't the manual pages be for 
people who don't know how to use the apps? To be frank, there are loads of 
Web tutorials and books about Unix which help a lot.

All these questions remind me, are there explanations of shell commands 
geared towards say Windows or DOS programmers, or folks knowing ANSI C with 
no assumed Unix-knowledge? Sometimes that would be highly useful. I like the 
tone in this excellent Ubuntu package tutorial:

http://www.monkeyblog.org/ubuntu/installing.html

and here's a Wiki I found which answers many of the Ubuntu questions I've 
had including the admin rights in Gnome:

http://ubuntuguide.org/wiki/Dapper

> alias cp='cp -v'
Just out of curiosity, can you still override that verbose flag on the 
command-line if the need be?

> Do you really want to hear all files that are being transfered?
Often I do. However, I tend to scan down the list and interrupt the speech 
frequently.

> echo *.foo*
Ah thanks. SO that would be something like:
print join "\n", <*.foo*>;
In Perl.

>> [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
Yep, that's why I'd really like to see an accessible GUI. Mind you've I've 
spend the last eight years or so in a GUi environment mostly. In that 
context, I like being able to do things without having to constantly think 
of how to do them. 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. IF I need to do anything more advanced 
I'll usually turn to automation or Perl and in that contextshare the 
programmer mindset willingly. I guess this is an attitude issue once again. 
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.

> Microsoft writes software for general public.
As does Apple, and many modern Unix apps are ment to be used by everyone. 
Which reminds me, 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.

> Note however: don't say "printing `cannot stat foo' sucks !,
Won't do that, thanks for reminding me, <smile>.

-- 
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/