Questions about windows support

[H. S. Teoh]

On Tue, Feb 21, 2012 at 06:22:25PM -0500, Nick Sabalausky wrote:
[...]
> That hadn't occurred to me. Thanks. Normally, the only time I use
> fg/bg is if I try to cancel something with Ctrl-blah and it suspends
> the process instead of stopping it. So then I "fg [whatever num]" and
> either try a different key combo or let it finish.

fg/bg is the best thing on earth since sliced bread. Well, to me. :)

It lets me fire up my (text-based) mail client, read mail halfway, find
someone mentioning an obscure library function, press ctrl-Z to suspend
to mail client, `man obscure_function` to find out on earth they're
talking about, then fg to continue reading mail.

Or, I'm doing some heavy D coding (yeah!), run into some syntax I'm
unsure about, so ctrl-Z to suspend vim, pushd /tmp, vim test.d, write
some test code, ctrl-Z the second vim, run gdc/dmd to see if a
particular construct compiles and does what I think it does, if not, fg,
edit more code, ctrl-Z, recompile, whoopie, it works now, fg, :q! to
exit 2nd vim, now fg %1 to get back to 1st vim, continue heavy D coding.

And somewhere in the midst of all that, the background music gets too
loud, so ctrl-Z to suspend whatever I was doing, run alsamixer to adjust
volume, quit, fg to resume what I was doing. (Or do the same thing when
music is finished, run mplayer to start new music, etc..)

All this, within a single rxvt terminal. I don't even have to switch to
a different window or take my hands off the keyboard. On a good day, I
can have up to 4 or 5 backgrounded processes, mostly vim sessions with
heavy D coding, perhaps a mail client, a 2nd mail client in the middle
of a long reply, a pager viewing an open manpage, etc..

Yeah. I'm such an ubergeek. :P  I only actually need more than one
terminal when dealing with spammy programs, like long-running large
compile jobs, or mplayer (unless I silence it with `echo -n | mplayer
... >/dev/null 2>&1&` -- the echo is there otherwise mplayer insists on
reading stdin from the terminal, which when it's backgrounded causes it
to get suspended by SIGTTOU -- yet another gratuitous tty annoyance
inherited from the old days). Or when I lose my geekiness and actually
switch to a GUI browser window. :P


> But still, I'd venture to say that probably 99.9% of the times you
> launch a gui app from the command line, you don't want, or at least
> don't need, it to be blocking or spamming the console. It'd be nice if
> it could do like windows and detect "gui or cmdline" so it can
> automatically do the right thing without the user coddling it.
> Unfortunately I'm not sure that's possible since I don't think Linux
> binaries are flagged as "cmdline or gui" like in windows. It just
> either calls some GUI apis or it doesn't.

Yeah. And worse yet, I've actually encountered GUI Linux apps that
expect input from stdin. I'm not kidding. As they say, fact is stranger
than fiction.


> That reminds me of another thing (yea, I know I sounds like I'm just
> ranting on and on about Linux, but I *do* rather like it overall):
> What the hell is up with this "sudo" vs "gtksudo/kdesudo" shit? I
> understand that it's somehow necessary for the
> permissions/process-owner stuff to all be right, but why should *that*
> be necessary?

Because Unix was designed with multiple users in mind. It has to ensure
that users don't stomp all over each other.


> The whole Unix philosophy is orthogonality, one tool to do one task
> well, no duplicated functionality for slightly-different use cases.
> The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort of
> big ugly hack.

It's to prevent people from doing foolish things like logging in as root
and doing everyday tasks as root, just because one or two commands
*might* require root privileges. It's convenient, it's like Windows and
DOS where you can do pretty much anything without this troublesome
protection thing. Like install programs and stuff.  Until one day you
want to remove everything from the current directory but instead type
this as root:

	rm -rf . /*

(The space between . and / is a typo... that you will regret for the
rest of your life.)

In the old days, you'd just be restricted to a non-root user, so certain
programs won't run (they need root access to, e.g., access a certain
hardware). You have to `su - root`, type in root's password, run the
program, then exit from root. Very tedious. Sudo lets you use your
*user* password and runs exactly a single command -- the one command
that actually *needs* root access. Everything else stays in non-root
space, so even if you screw up and destroy your entire home directory,
the system itself is still intact and you can still recover.

Whereas the above command, running as root, will likely cripple your
system in the few seconds before you notice something is wrong, and
quite possibly ruin your entire day (and the next 2 days) in the
following few seconds before you react and hit ctrl-C. Depending on what
order rm tries to delete stuff, by the time you stop it there may not be
anything left in /bin or /usr/bin, and then you'll have to be macho and
use echo commands to recreate binary files. :P :P :P


T

-- 
This sentence is false.