Re: nice troll (was: All this resource-fork AKA multiple stream nonsense)

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Fri, 9 Jul 1999 19:14:51 +0200


Nathan Hand wrote:
> > 1. Because the user, for one reason or another, has to use
> > the command line occasionally. These users will be even
> > more confused when the command line presents a different
> > filesystem to the GUI.
>
> How often does a Macintosh user see the command line?
>
> Is it a requirement of Windows 95 to use the DOS prompt?
>
> Heck, Windows 95 *does* present a different filesystem when you're at
> the command line (suddenly everything has abbreviated names). I'm not
> arguing this means Windows 95 is a good design, but rather that it is
> not as much a stumbling block for users as you're making out.

We're aiming for something better than Windows.

Unix has traditionally had a more powerful and useful command line
than Windows -- and people use it a lot more.

> I think this is a fabricated reason to put the functionality into the
> kernel. GUI users *don't* use the command line. People who do use the
> command line will understand the implications and will move the whole
> directory (using tar, or recursive copy).

GUI users _do_ use the command line.
That is my religous stance of the day.

I'm a fscking GUI user -- I use netscape, gv, Lyx and gimp extensively,
and I also use the command line a lot. And the apps I use make
_extensive_ use of command line apps.

e.g. When clicking on "Gimp->File->Email image" works by invoking
"cat image | sendmail -options '<address>'" I expect it to just work.

This is the argument for presenting the same filesystem to all apps.

> > 2. Because GUI apps often invoke command line apps to do the
> > work. If the GUI thinks there's a file somewhere, it will
> > expect the command line app it invokes to find the same thing.
>
> This is a programming issue not a user issue. You might as well argue
> that /proc is broken by design because procutils needs to be modified
> every now and then to understand new entries.

??? Are you saying GUI apps should never invoke existing command line apps?
Or that all command line apps should be changed?

> > 3. Because users who prefer the command line want the same
> > features with the same ease of use, just no GUI.
>
> Then fix the shell. Bash isn't in the kernel.

The shell has nothing to do with command line apps seeing the right
files. It may be able to do completion and wildcards on albods, but
then how does it sensibly invoke apps?

> For another example of shell magic consider the dotfile standard. The
> kernel doesn't have a "hidden" bit. The shell and GUI alike both hide
> files beginning with a period. Why is this impossible for albods?

Because "hidden" is by definition a shell-only, GUI-only thing.
It doesn't affect the behaviour of command-line apps.

But if I invoke "zcat some_file_that_only_exists_in_GUI.gz", you're
suggesting it should fail?

> > BTW I'm arguing here that the GUI and command line should have
> > consistent views. Nothing to do with the kernel per se.
>
> Why? They're different things. Why should they look the same?

Because they're interconnected. GUI apps often invoke non-GUI apps and
vice versa. People use the command line because it's powerful and
because you can write decent scripts. Even GUI scripting is done using
shell scripts. This is unix, not DOS.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/