On a related issue, I agree that shell quoting is a ridiculously complex
discipline to thrust upon the webtv generation. It's too far from their
real concerns, since most of them aren't "fine points of
context-dependent token recognition" aficionados. I just don't agree that
exporting gui windows (or compiled object code executable by remote
guis, ie Active Security Breach) over telecom backbones is necessarily the
only solution to the problem.
It's like having a tree obscuring a stop sign and building a bridge
over the intersection instead of moving the tree.
Regards,
--
Clayton Weaver
<·············@eskimo.com>
(Seattle)
* Clayton Weaver <······@eskimo.com>
| On a related issue, I agree that shell quoting is a ridiculously
| complex discipline to thrust upon the webtv generation.
It's unclear to me who you agree with.
| It's too far from their real concerns, since most of them aren't
| "fine points of context-dependent token recognition" aficionados.
That's not what quoting is about, so what is this?
| I just don't agree that exporting gui windows (or compiled object
| code executable by remote guis, ie Active Security Breach) over
| telecom backbones is necessarily the only solution to the problem.
I must have missed something. Are anyone favoring this?
#:Erik
--
If this is not what you expected, please alter your expectations.
* Clayton Weaver <······@eskimo.com>
| On a related issue, I agree that shell quoting is a ridiculously
| complex discipline to thrust upon the webtv generation.
It's unclear to me who you agree with.
| It's too far from their real concerns, since most of them aren't
| "fine points of context-dependent token recognition" aficionados.
That's not what quoting is about, so what is this?
| I just don't agree that exporting gui windows (or compiled object
| code executable by remote guis, ie Active Security Breach) over
| telecom backbones is necessarily the only solution to the problem.
I must have missed something. Is anyone favoring this?
#:Erik
--
If this is not what you expected, please alter your expectations.
(A bit far afield from the original subject, which was redundancy of
argc in main()'s function parameters, to shell quoting affecting
what a program sees for argc and argv[], to whether inspecting
argv[] elements for aggregated multiple command options is wise
or not, to user interface design, where shell quoting is designed to
disambiguate elements of command line user interfaces, but then its
summer, the subject fits under the umbrella of user-visible program
design, which applies to people using any high-level language, so ...)
"quotes suck"
That was in the argc thread. I understand the sentiment. When I explain
shell quoting to new users, the programmers say ok and make a mental
note to keep the man page and some sample scripts handy to refer
back to if they get unexpected results, while the non-programmers make a
mental note to find out whether there is a gui version that they can use
instead.
Documents that I've come across studying user interface design tend
to recommend layering, separating what the user sees from what the
program sees when it runs (the user syntax and the runtime arguments
syntax are contexts with different syntax rules and a mapping between
them). There is an implied translation layer in this sort of design
between the user's interface to a command and the command interpreter's
interface to a command, and each can use the syntax rules most
convenient for that context, as long as the mapping from one to
the other is unambiguous.
My view is that this is ok for local interactive interfaces but something
of a handicap for scheduled batch processing, unnecessary overhead for
distributed remote commands, and it's also unnecessary overhead if you
have a user handy that can use a command line shell without
virtually burning down the office.
If I want to send a command to a remote branch office to send me the
quarterly report, for example, I think that should be a one-liner
that fits in one packet, in a syntax that an assistant can learn
in 15 minutes without having to learn how to quote shell command lines in
all of their historic complexity. I shouldn't have to send a whole
team of packets to build a sign in a window in the remote host to
tell it to send me the report, merely to take the complexity of shell
quoting out of the job.
If I have to choose between the complexities of command line shell
quoting and a gui interface to what should be simple commands, I'm still
going to choose the shell, because
a) I already know it;
b) for batch jobs, I only have to figure out the quoting once,
no matter how complex it is initially, and once it is right the
command runs correctly on demand an indefinite number of times
without the overhead of a layered gui's command interpreter
translating the command syntax from the user interface syntax to the
disambiguated command interface syntax;
c) I use less bandwidth running command on remote hosts.
The choices aren't cut and dried, of course. You can run a local gui
and ship the disambiguated command instead of the window, if you
can go around the gui that's local to the remote system and run programs
directly in a remote environment free of reinterpretation of the command
and its options by the layered command interpreter that a user logged
into the remote gui would use to interpret commands.
Guis are ok in their element (interactive users at local consoles who
can see them), but not the only possible solution to unambiguous command
syntax.
I mean, the basic problem is context-dependent textual ambiguity in
command lines, not text mode itself. I question whether the gui
sledgehammer is needed to solve the complexity of shell quoting problem,
even if its a reasonable approach for the average interactive home
user.
One could of course take the position that I was in error in suggesting
argv[n] splitting under any circumstances, and that anyone who can't
keep their command options separate in the shell command line with
current methods should use a gui instead and leave the intricate stuff
to the experts. I admit that this position does simplify the argv[] issue,
making getting the quotes right entirely the user's problem, which at
least has simplicity of coding to recommend it.
Finally, as a matter of mere personal impression, GUIs seem to me quite
horrible, unwieldy blunt instruments, on average. When I first saw
one, I was mightily impressed with having the command options
available on a menu. But after using them for awhile, they seem to
lack a certain expressive nimbleness that you have with a unix command
line shell, which leads me to jump through whatever hoops are necessary to
avoid them whenever there is another way to get the same job done.
That might be just code quality in immature operating environments, but I
always feel like Brer Rabbit looking at a nicely rendered brier patch when
I sit down in front of one. That may be one reason why a more
user-friendly (less complex, less ambiguity to disambiguate) command line
shell syntax seems a more inviting target to me than "upgrading" from
text mode to a GUI. One needs the GUI for graphics, of course, but I
certainly don't need one to scan text or operate on numbers.
Regards,
--
Clayton Weaver
<·············@eskimo.com>
(Seattle)
Clayton Weaver <······@eskimo.com> writes:
> On a related issue, I agree that shell quoting is a ridiculously complex
> discipline to thrust upon the webtv generation.
(in-package :RANT)
Rest assured, no expense is spared to dumb down what was once
reasonably usable to the intelligence level of the redneck couch
potato. There used to be a time when you had search engines that
understood regular expressions, quoting, the NEAR keyword and that
allowed you to specify precisely what you were looking for. These
days, you're supposed to enter a question and after clicking go some
stupid program will try to guess what you had in mind by throwing away
everything that looks like a common word, massacring diacritical
marks, truncating common suffixes it thinks it has found and after
having done that, it will proceed to give you pages of hits that
certainly don't match your original query.
--
Lieven Marchand <···@bewoner.dma.be>
When C++ is your hammer, everything looks like a thumb. Steven M. Haflich
In article <··············@localhost.localdomain>, Lieven Marchand wrote:
>Clayton Weaver <······@eskimo.com> writes:
>
>> On a related issue, I agree that shell quoting is a ridiculously complex
>> discipline to thrust upon the webtv generation.
>
>(in-package :RANT)
>
>Rest assured, no expense is spared to dumb down what was once
>reasonably usable to the intelligence level of the redneck couch
>potato. There used to be a time when you had search engines that
>understood regular expressions, quoting, the NEAR keyword and that
>allowed you to specify precisely what you were looking for. These
>days, you're supposed to enter a question and after clicking go some
>stupid program will try to guess what you had in mind by throwing away
>everything that looks like a common word, massacring diacritical
>marks, truncating common suffixes it thinks it has found and after
>having done that, it will proceed to give you pages of hits that
>certainly don't match your original query.
>
>--
>Lieven Marchand <···@bewoner.dma.be>
>When C++ is your hammer, everything looks like a thumb. Steven M. Haflich
This comes under the heading of progress.
The above comment may or may not be a statment of fact, it could go either way.
marc spitzer