Re: [tlug] Arcane command-line (Was: epcEditor)

[Matt Doughty <mdoughty@example.com>]

> 
> You must just pine for TECO, then.
> 
>     Matt> and much like programming languages if you make it more
>     Matt> readable/verbose you negatively affect their power (see:
>     Matt> cobol).
> 
> Interesting argument.  But I tend to disagree.  I like the GNU long
> options, because often I can just guess what the right options are.
> Eg, the other day I was mucking with ipchains for the first time in a
> while, and I wanted to shut out the guy hammering on port 8473.  (It
> was generating a lot of log entries.)  Without reading the manual, I
> hit on
> 
>             ipchains -A input --destination-port 8473 DENY
> 
> Of course I then got a syntax error and had to read the manual anyway,
> but that's not bad for just guessing, is it?

I don't disagree with the value of the long options, but if you
implement them to the exclusion of the short options you lose power.
A good example could be seen in an imaginary ls command with long
options as opposed to the standard fare:

ls --long --all-files

is very readable, but certainly a time loss compared with:

ls -la 

When one is typing the commands on regular basis taking away the option
to terse is effectively taking away your time. In perfect world however
all unix commands would implement matching pairs of short, and long 
options and we would have the best of both worlds in a consistent manner.
Dreaming is a wonderful thing. ;)

> 
> I think the real power of the command line is that it is _not_ "much
> like" a programming language, it _is_ a programming language.  For
> example, Steve Baur wrote a BASIC interpreter in ksh once.  The point
> is that it has a rich, expressive syntax.

I was trying to address the advantages those short cryptic commands with
their terse options, and sometimes idiosycratic syntax. While ps and ls 
may be hard to comprehend they are much more functional that process and
list-files even if the later are much easier to comprehend. I carefully
stepped around shells because while related to the discussion I felt
it was spreading the coversation to far, but you have hit on something that
I certainly agree with.  The shell is a language, and once you know how to
speak with it you can tell the computer to do whatever you want. It provides
a freeform interface that allows extremely flexible control of the system. 

> 
> The weakness of GUI, as I realized well after writing my previous
> screed, is that current GUI tools provide no syntax beyond "collection
> of items in a box."  With the single exception of the spreadsheet,
> there is no common GUI with an _input_ syntax beyond "collection".
> Sure, even Athena provides a tree widget, but it doesn't allow you to
> rewrite that tree.  Glade just allows you to collect a bunch of
> widgets.  Etc.
> 
> Of course there's some CAD and CASE available, but not for the kinds
> of purposes that we use shells for.
> 

I sometimes give thought to this, and It seems to me that the weakness
in many gui tools is that they amount to a phrase book that is very quick
when it says what you want to say, especially if you don't understand 
the underlying language.  If you want to do something a little different
though you can quickly find yourself SOL.  Its almost as if you have to
sacrifice flexiblity for ease of use. It could be that you can only say
so much with a point and a click.  It could be the lack of a workable
freeform graphical framework that is holding it back.  Film certainly is
still unable to capture much of what is expressed in books and not for a
lack of trying. I have a feeling that the problem space is beyond my ability 
to comprehend, and I am just glad I have my command line. :)

--Matt
-- 
"Take away them collisions and the common channel and it's like Christianity 
 without Christ." -Jim Breen (speaking about "full-duplex" Ethernet)