I repeat what I'd said, "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".
And I find the whole "we" rhetoric very tiring. Linux isn't a homogenous
all-agreeing whole. You can speak for yourself, but try not to speak for
all Linux users as if you're the group-appointed spokesperson.
> Unix has traditionally had a more powerful and useful command line
> than Windows -- and people use it a lot more.
And these users have enough brains to tar up directories before treating
them like flat files. If they aren't smart enough to do this, then maybe
they should stick to the GUI.
> > 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.
I repeat myself, "People who do use the command line will understand the
implications and will move the entire directory (using tar, or recursive
copy)".
> 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.
Why?! Command lines don't have icons. Command lines don't show directory
trees next to files. Command lines don't support URL or FTP windows like
kfm or gmc does. Command lines don't support "tgz windows". [1]
The differences are already fundamental and vast. You are trying to bail
water from the ship with a thimble. It's a pointless exercise to try and
make the command line like the GUI in this tiny (not needed) way.
[1] Midnight commander does, but midnight commander and their ilk are in
reality more like GUI apps (they provide a unique environment that tries
hard to isolate the user from the command line).
> > > 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?
I'm saying that a GUI app can use tar and recursive copy as well.
> > > 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?
If you want the tools to behave differently, fix the tools, don't change
the way the kernel works. The kernel provides mechanism not policy. User
space is what provides policy. The kernel provides the means to do so.
<DONT RESPOND HERE, READ BOTH PARAGRAPHS FOR CONTEXT>
You can do the forked files in userspace. Your arguments so far are that
you do not want to fix the hundreds of command line tools which will not
understand. This is an argument of laziness, not of elegant design.
> > 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?
I'm suggesting you're intentionally creating strawmen (3 so far). It has
no merit to create obviously stupid arguments and then pretend that your
opponent is arguing this way. Stop doing it.
> > > 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.
Programmers are even smarter than command line users, they're definitely
smart enough to popen("tar czvf albod") instead of open("albod", 1). I'm
of the opinion that normal users can figure this out too.
And that's your 4th strawman. I'm not a DOS user, I'm not arguing from a
DOS perspective, so stop trying to imply that anyone that disagrees with
you is simply a stupid "non-UNIX" person.
--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au
-
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/