Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
From: scott@yarc.uucp (Scott Beckstead)
Date: Wed, 11 Nov 1992 19:45:57 GMT
Reply-To: scott@yarc.UUCP (Scott Beckstead)
Organization: Yarc Systems

In article <aldavi01.721333614@starbase.spd.louisville.edu> Arlie Davis <aldavi01@starbase.spd.louisville.edu> writes:
>In comp.unix.misc you write:
>
>> I am doing research on UNIX command line interface problems.
>> I am sure everyone has his/her favorite UNIX troubles, would
>> you post or email me what's your favorites?  What should have
>> been done by UNIX to resolve that problem in general?
>
>Are you sure you are researching the command line interface?  None of your
>examples below seem to suggest so.
>
>> Does anybody know of excellent papers in this area?  I know 
>> about Norman's "The Trouble with UNIX".
>
>> To start the discussion, consider the following problems:
>
>>     cat a b > b
>
>>     This is a general problem of trying to modify the input
>>     file.
>
>This has nothing at all to do with the command line interface.  This is simply
>an *error* in user semantics.  What should cat do?  Stick in a feedback loop?
>No, this is definitely an error on the user's side.
>
>>     rm -filename_with_a_hyphen
>
>>     This is a general problem of name clash (clashing filename
>>     with command options.)
>
>True, but it is a trivial one.  *All* UNIX filenames can specified explicitly
>with a full pathname (such as "rm /tmp/foo/bar/-filename_with_a_hyphen" or
>"rm $PWD/-filename_with_a_hyphen"), or as a relative directory, starting with
>the parent directory ".." or the current directory "." (such as
>"rm ./-filename_with_a_hyphen").
>
>Also, again, this has nothing at all to do with the command line interface,
>the "shell".  How programs interpret their argument vector is entirely up
>to them.  The shell only passes on what the user types.
>
>>     mail somebody < a.out
>
>>     Sending binary file should be uuencoded first.  This is a
>>     general type conflict problem.
>
>Again, this is an error on the *user's* side.  This has nothing to do with the
>shell!  Yes, you could create a mail script wrapper that checked the magic cookie
>of the file being sent (see file(1)), and uuencoded if necessary.  But this is
>completely different from the shell.
>
>> Bryan So
>-- 
>lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null

  I think this is kinda what he is trying to determine.  Typicaly UNIX
imposes far more structure on the user than is desired.  I agree an
experienced user should be able to recognize and avoid the problems
above.  What's wrong with the shell catching such obvious errors and
either reporting them or taking other appropriate action (ie correcting
them).  I realize that this will get me screamed at by all you guru
types that advocate that all shell users be rocket scientists or why
bother using a computer anyway.  However I see no reason NOT to research
the subject.  If UNIX could be made more user friendly by modifying the
shell it might gain more acceptance in the general microcomputer market
place, GUIs not withstanding.
Scott


-- 
Reply to: scott@yarc.uucp 	|  
				|	Spin my nipple nuts and send me to   
  Smoke me a kipper, I'll be	| 	Alaska.
   back for breakfast	 	|       
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc