[9fans] Fork: useless and painful?

[9fans] Fork: useless and painful?

[Joel Salomon]

Dan Cross wrote:
> Oh, I turned that junk off.  Ls is aliased to ls -1A and lc is aliased to
> ls | mc, as it should be (using my Unix version of mc).

Where can I get your unix mc from?
--Joel

Re: [9fans] Fork: useless and painful?

[Dan Cross]

> > Oh, I turned that junk off.  Ls is aliased to ls -1A and lc is aliased to
> > ls | mc, as it should be (using my Unix version of mc).
>
> Where can I get your unix mc from?

ftp://ftp.math.psu.edu/pub/cross/src/mc.c

Let me know if you have any problems with it.

	- Dan C.

[9fans] Fork: useless and painful?

[Joel Salomon]

>>> Oh, I turned that junk off.  Ls is aliased to ls -1A and lc is aliased
>>> to ls | mc, as it should be (using my Unix version of mc).
>>
>> Where can I get your unix mc from?
>
> ftp://ftp.math.psu.edu/pub/cross/src/mc.c
> Let me know if you have any problems with it.

Well, right now I can't access the site :-(
I'll try again sometime tomorrow - I've been looking for something like
this for a while.

In the meantime, I've aliased ls to ls -1A and lc to /bin/ls -AC --color
But somehow, there is a noticeable delay before I see my output. *n#ix!

--Joel

Re: [9fans] Fork: useless and painful?

[Jack Johnson]

Joel Salomon wrote:
> Dan Cross wrote:
>>Oh, I turned that junk off.  Ls is aliased to ls -1A and lc is aliased to
>>ls | mc, as it should be (using my Unix version of mc).

Excuse my '80s-ism, but: DUDE!

I never realized 'mc' was part of 9pm, and I always missed 'lc'.

I am so hyped.

-Jack (easily amused)

Re: [9fans] Fork: useless and painful?

[Jim Choate]

On Fri, 1 Aug 2003, Jack Johnson wrote:

> Excuse my '80s-ism, but: DUDE!

Actually that's originally a person who can't ride a horse (goes back to
sometime in the 1800's), it was used that way until the late 60's and early
70's when disco folks picked it up. From there it's just become a general
expression.

I'd almost be willing to bet you were born in the 60's (probably late).


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Fork: useless and painful?

[Jack Johnson]

On Fri, 2003-08-01 at 15:26, Jim Choate wrote:
> On Fri, 1 Aug 2003, Jack Johnson wrote:
>
> > Excuse my '80s-ism, but: DUDE!
>
> Actually that's originally a person who can't ride a horse (goes back to
> sometime in the 1800's), it was used that way until the late 60's and early
> 70's when disco folks picked it up. From there it's just become a general
> expression.

As a noun, referring to a man in excessive/fancy attire, it stems from
the late 1800 during America's westward expansion, literally from the
"duds" they were wearing.

As a replacement for "mister" or "sir" the usage comes from the '60s,
also from the difference in attire compared to the "hippies".

The evolution into generic interjection comes from the early '80s.

> I'd almost be willing to bet you were born in the 60's (probably late).

'70, which is close enough, I suppose.

-J

Re: [9fans] Fork: useless and painful?

[ron minnich]

On Mon, 14 Jul 2003, Lucio De Re wrote:

> I thought the object oriented paradigm would at least be able to hide
> that from the programmer.  Weird...

The weirdest thing about the "OO paradigm" is how badly it is done in so
many places.

I was looking at one "OO" os. Floppy, disk, console, etc. were all
different types of "objects", all accessed very differently. What's the
point of OO if you do that type of thing?

ron

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I thought the object oriented paradigm would at least be able to hide
> that from the programmer.  Weird...

one might like to think so.  the problem stems from the fact that winsock
was justa a bolt-on to windows 3 and it's always been like that.  it never
got integrated into the rest of the mess ['95/'98/NY] correctly.

windows might have a lotta C++ in it but the 'syscall' interface is classic.

it truly is a ghastly mess.

Re: [9fans] Fork: useless and painful?

[Lucio De Re]

On Mon, Jul 14, 2003 at 08:51:34AM +0000, John Kodis wrote:
>
> In article <85139cb0363c3b2b1f14746d68b9ff59@plan9.bell-labs.com>,
> David Presotto wrote:
>
> >  Not to mention the fact that you have to send/receive on sockets
> >  and read/write on everything else so that an app has to check
> >  the type of any handles it is passed so that it can use the
> >  right calls.
>
> Nor to mention the fact that you have to pclose on process streams and
> fclose on everything else so that an app has to check the type of any
> streams it is passed so that it can use the right calls.

I thought the object oriented paradigm would at least be able to hide
that from the programmer.  Weird...

++L

Re: [9fans] Fork: useless and painful?

[John Kodis]

In article <85139cb0363c3b2b1f14746d68b9ff59@plan9.bell-labs.com>,
David Presotto wrote:

>  Not to mention the fact that you have to send/receive on sockets
>  and read/write on everything else so that an app has to check
>  the type of any handles it is passed so that it can use the
>  right calls.

Nor to mention the fact that you have to pclose on process streams and
fclose on everything else so that an app has to check the type of any
streams it is passed so that it can use the right calls.

Re: [9fans] Fork: useless and painful?

[Andrew Lynch]

On Jul 10, 10:17pm, David Presotto wrote:

> I just tried a ReadFile on a socket on my NT system and it
> failed miserably.

You should upgrade to XP. There it fails with a smile on its face.

Andrew.

Re: [9fans] Fork: useless and painful?

[ron minnich]

On Thu, 10 Jul 2003, David Presotto wrote:

> Not to mention the fact that you have to send/receive on sockets
> and read/write on everything else so that an app has to check
> the type of any handles it is passed so that it can use the
> right calls.

and if memory serves, sendto/recvfrom won't work on tcp sockets (they do
on *bsd)  so you not only need to have exact knowledge of it being a
socket, and what type of socket it is.

W32 is in many ways the evil counterexample to Plan 9.

ron

Re: [9fans] Fork: useless and painful?

[D. Brownlee]

>>Look, we don't want SIGINT, okay???
>
>
> yes you do.  SIGINT kills the proc.  on windows the 'process' is asked to
> 'call it quits' and that doesn't really work, especially when the 'process' in
> in a hung state and is less than cooperative.
>
>

On Win2k the task mgr. will say something like,
"Process not responding. Do you want to end it now and lose your data?"
So, they must have some way of killing it.

Re: [9fans] Fork: useless and painful?

[Alexis S. L. Carvalho]

Thus spake Geoff Collyer:
> To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
> sort order and change to all-numeric uglies?  I'm an English-speaker
> in the US who prefers UTF-8, and I don't want any of this rubbish.

(Please don't shoot me for knowing this...)

There are quite a few locale categories - LC_CTYPE specifies the
encoding used, LC_COLLATE the sorting order and so on.  You can see
their current value using the command locale.

LANG specifies the default value for all categories;  you can override
one particular category with LC_CTYPE, LC_COLLATE etc.

LC_ALL overrides both LC_* and LANG.

In a nutshell: use LANG=C and LC_CTYPE=en_US.UTF-8 and you should be
happier.

Alexis

Re: [9fans] Fork: useless and painful?

[matt]

>
>
> the fact that it
>seems to consist of a random collection of constantly changing APIs
>designed, if that's the right word, by different groups of people who never
>talked to each other about things such as a uniform method for reporting
>errors.
>
>

that's a business model, those MSDN subscriptions aren't free ya know


[at least they weren't free the day I stopped reading them]

Re: [9fans] Fork: useless and painful?

[Douglas A. Gwyn]

boyd, rounin wrote:
>>Look, we don't want SIGINT, okay???
> yes you do.  SIGINT kills the proc.  on windows the 'process' is asked to
> 'call it quits' and that doesn't really work, especially when the 'process' in
> in a hung state and is less than cooperative.

Actually SIGINT is a signal that can be caught or ignored
by the process, leading to a hang under some conditions.
SIGKILL can't be caught or ignored.  The recommended
procedure for terminating a process forcefully is first
send it a SIGHUP, then a SIGTERM, then a SIGKILL.  That
gives it a chance to clean up properly but if the process
isn't cooperative then it is killed eventually.

Re: [9fans] Fork: useless and painful?

[northern snowfall]

>
>
>>Look, we don't want SIGINT, okay???
>>
>
>yes you do.  SIGINT kills the proc.
>
Forget SIGINT. Semantics say that can be caught, and
a hung process catching on Win isn't likely to yeild
any different results. SIGKILL enforcement sounds
nicer to me :/

Don

http://www.7f.no-ip.com/~north_

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> SIGKILL enforcement sounds nicer to me :/

yup, but being able to hit DEL and the proc (in general) gets blown
away without any nonsense about:

    well that there varmit of a proc is a might contrary and would ya
    like to blow its head ... clean off or take a sip of JD while it
    decides if it's gonna to get the hell out of dodge, y'all?

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Look, we don't want SIGINT, okay???

yes you do.  SIGINT kills the proc.  on windows the 'process' is asked to
'call it quits' and that doesn't really work, especially when the 'process' in
in a hung state and is less than cooperative.

[9fans] Fork: useless and painful?

[Andrew Simmons]

> jesus, these fools don't even have SIGINT.Look, we don't want SIGINT,
okay??? At least, I'm sure we wouldn't if we knew what it was. Now leave me
alone while I attempt to follow your wrist-slashing instructions.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Actually, under Winsock2 you

should cut up, not across.  if you want to slash your wrists correctly.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I just tried a ReadFile on a socket on my NT system and it
> failed miserably.

absolutely.  you have to cut the code into one chunk that deals with
'files' and another that deals with 'sockets' and that means threads.

jesus, these fools don't even have SIGINT.

it truly is ghastly.  it's windows 3 with dave cutler's footprints over
everything.

Re: [9fans] Fork: useless and painful?

[David Presotto]

I just tried a ReadFile on a socket on my NT system and it
failed miserably.

[9fans] Fork: useless and painful?

[Andrew Simmons]

>Not to mention the fact that you have to send/receive on sockets
>and read/write on everything else so that an app has to check
>the type of any handles it is passed so that it can use the
>right calls.
Actually, under Winsock2 you can use ReadFile/WriteFile with sockets as well
as file handles. You can also use WaitForMultipleObjects, not on the socket
handle itself, but on an event object which is triggered when eg there is
data available for reading. Admittedly you'd never know this from the
documentation, which says you have to use WSAWaitForMultipleEvents, and use
WSAEvents rather than regular Windows events.

The main problem I have with Windows is not the bazillion parameters for
each function call, which you soon learn to ignore, but the fact that it
seems to consist of a random collection of constantly changing APIs
designed, if that's the right word, by different groups of people who never
talked to each other about things such as a uniform method for reporting
errors.

Re: [9fans] Fork: useless and painful?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Not to mention the fact that you have to send/receive on sockets
and read/write on everything else so that an app has to check
the type of any handles it is passed so that it can use the
right calls.

[-- Attachment #2: Type: message/rfc822, Size: 2698 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Fork: useless and painful?
Date: Thu, 10 Jul 2003 21:57:22 +0200
Message-ID: <006601c3471d$7a06de40$b9844051@insultant.net>

> Where is the joy in computing? Win32 is making me wonder.

been there, done that.  a repeat of SysVile (sic) R3:

    you could select on a socket or poll on a stream,
    but they would not interoperate

on NT you need to call WaitForMultipleObjects() iirc and
that doesn't work on WinShlock (sic) sockets etc, so you
have to use a threaded implementation.

for extra points, if the NT CreateSocket() call finds that you
are _not_ WinShlock (sic) the call fails and returns -6 iirc.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> As an aside, UWIN's rshd is just as bad, and Cygwin's is worse.
> I'm guessing Microsoft's telnetd is fairly brain dead in this
> respect, as well.

yeah, i had to write an rsh client -- arrgh ...

Re: [9fans] Fork: useless and painful?

[Stephen Wynne]

And I just got a suggestion to use named pipes, presumably because
they have a richer set of buffering options.

I don't think named pipes help one with the situation where a
DOS program does direct console I/O. I think "net use" does
that when it prompts you for a password; you get the idea,
in any case. My line buffering app is cacls.exe (don't laugh).

I don't think I am going to work on this more right now, but
if I were, I would try to replace the standard I/O via plain pipes
connected to winsock sockets with standard I/O through dedicated
but hidden consoles for each connection. I think it's possible.

As an aside, UWIN's rshd is just as bad, and Cygwin's is worse.
I'm guessing Microsoft's telnetd is fairly brain dead in this
respect, as well.

boyd, rounin wrote:
>>Where is the joy in computing? Win32 is making me wonder.
>
>
> been there, done that.  a repeat of SysVile (sic) R3:
>
>     you could select on a socket or poll on a stream,
>     but they would not interoperate
>
> on NT you need to call WaitForMultipleObjects() iirc and
> that doesn't work on WinShlock (sic) sockets etc, so you
> have to use a threaded implementation.
>
> for extra points, if the NT CreateSocket() call finds that you
> are _not_ WinShlock (sic) the call fails and returns -6 iirc.
>
>

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Where is the joy in computing? Win32 is making me wonder.

been there, done that.  a repeat of SysVile (sic) R3:

    you could select on a socket or poll on a stream,
    but they would not interoperate

on NT you need to call WaitForMultipleObjects() iirc and
that doesn't work on WinShlock (sic) sockets etc, so you
have to use a threaded implementation.

for extra points, if the NT CreateSocket() call finds that you
are _not_ WinShlock (sic) the call fails and returns -6 iirc.

Re: [9fans] Fork: useless and painful?

[Stephen Wynne]

David Presotto wrote:

> It's amazing how awkward win32 makes all of the same.  Every
> process control call turns into a handful of calls, each with
> a dozen params.

Yes, I'm noticing! On a related note, since I've been looking at
how to solve the probelm with console hacking:

Lately I've been wanting pseudo terminals because my rshd.exe
gives me stdout in line buffered mode, causing un-line-terminated
program prompts to only be output after the program exits (if
at all). I haven't tried to run anything that reads or writes directly
to the console yet, but I trust those kinds of programs are common
enough.

Where is the joy in computing? Win32 is making me wonder.

Re: [9fans] Fork: useless and painful?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

That's why we have libthread with its threadcreate/proccreate/procexec.
I've been moving stuff over to windows and just kept the libthread
interface.

It's amazing how awkward win32 makes all of the same.  Every
process control call turns into a handful of calls, each with
a dozen params.

[-- Attachment #2: Type: message/rfc822, Size: 3652 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Fork: useless and painful?
Date: Thu, 10 Jul 2003 15:59:34 +0100
Message-ID: <212c59d55eb25badcbc00c9fe4121065@vitanuova.com>

> I'm hearing the claim that fork is "useless and painful" (from an IBM K42
> guy).
>
> Maybe it's just me, but I've always liked fork.

fork's kinda nice, but can be confusing.
plan9 has really moved away from fork for multithreaded programs
towards the "spawn" style proccreate.  (rfork for other resource
attributes is quite different, i think)

a day or so ago, i had occasion to write the following code:

	int
	mpipe(void)
	{
		char buf[BUFSIZE];
		int n, p[2];

		pipe(p);
		if(fork() == 0){
			if(fork() == 0){
				close(p[1]);
				return p[0];
			}
			close(p[0]);
			while((n = read(0, buf, sizeof(buf))) > 0)
				write(p[1], buf, n);
			exits(nil);
		}
		close(p[0]);
		while((n = read(p[1], buf, sizeof(buf))) > 0)
			write(1, buf, n);
		exits(nil);
	}

there's nothing particularly complicated going on and i don't *think*
the implementation is particularly obtuse, but i don't find reading
that code straightforward.

here's a different structure to the same end:

	int
	mpipe(void)
	{
		int p[2];
		pipe(p);
		spawn copy(0, p[1]);
		spawn copy(p[1], 1);
		return p[0];
	}

	void
	copy(int fd0, int fd1)
	{
		char buf[BUFSIZE];
		int n;
		while((n = read(fd0, buf, sizeof(buf))) > 0)
			write(fd1, buf, n);
	}

ok, i cheated, assuming that C has been given a "spawn" statement
similar to Limbo's.  nonetheless, i think the structure itself is
clearer, and the meaning of the code more transparent - no possibility
of accidentally duplicating the *caller* of mpipe...

given that forking a process in plan 9, unlike unix, is not synonymous
with forking its file descriptors, surely the only real reason to
prefer it is that the call fits more nicely into the C syntax; one
doesn't have to bypass typechecking in order to pass arguments to a
new process.

how often does anyone do anything with fork that could not be done at
least as easily with spawn?

Re: [9fans] Fork: useless and painful?

[rog]

> I'm hearing the claim that fork is "useless and painful" (from an IBM K42
> guy).
>
> Maybe it's just me, but I've always liked fork.

fork's kinda nice, but can be confusing.
plan9 has really moved away from fork for multithreaded programs
towards the "spawn" style proccreate.  (rfork for other resource
attributes is quite different, i think)

a day or so ago, i had occasion to write the following code:

	int
	mpipe(void)
	{
		char buf[BUFSIZE];
		int n, p[2];

		pipe(p);
		if(fork() == 0){
			if(fork() == 0){
				close(p[1]);
				return p[0];
			}
			close(p[0]);
			while((n = read(0, buf, sizeof(buf))) > 0)
				write(p[1], buf, n);
			exits(nil);
		}
		close(p[0]);
		while((n = read(p[1], buf, sizeof(buf))) > 0)
			write(1, buf, n);
		exits(nil);
	}

there's nothing particularly complicated going on and i don't *think*
the implementation is particularly obtuse, but i don't find reading
that code straightforward.

here's a different structure to the same end:

	int
	mpipe(void)
	{
		int p[2];
		pipe(p);
		spawn copy(0, p[1]);
		spawn copy(p[1], 1);
		return p[0];
	}

	void
	copy(int fd0, int fd1)
	{
		char buf[BUFSIZE];
		int n;
		while((n = read(fd0, buf, sizeof(buf))) > 0)
			write(fd1, buf, n);
	}

ok, i cheated, assuming that C has been given a "spawn" statement
similar to Limbo's.  nonetheless, i think the structure itself is
clearer, and the meaning of the code more transparent - no possibility
of accidentally duplicating the *caller* of mpipe...

given that forking a process in plan 9, unlike unix, is not synonymous
with forking its file descriptors, surely the only real reason to
prefer it is that the call fits more nicely into the C syntax; one
doesn't have to bypass typechecking in order to pass arguments to a
new process.

how often does anyone do anything with fork that could not be done at
least as easily with spawn?

Re: [9fans] Fork: useless and painful?

[Derek Fawcus]

On Thu, Jul 10, 2003 at 09:22:39AM +0200, boyd, rounin wrote:
> > To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
> > sort order and change to all-numeric uglies?  I'm an English-speaker
> > in the US who prefers UTF-8, and I don't want any of this rubbish.
>
> yup i bitch to google about such, err, assumpions.
>
> so i'm in oz, so i'm australian.
>
> i'm in france so i'm french.
>
> i'm in sweden so i'm swedish.

Oh - I can beat that.   I'm in the UK,  but if I use google.com I get it
in Dutch.  That's would appear to be 'cause our network connectivity pops
outside of the company in Amsterdam...

DF

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
> sort order and change to all-numeric uglies?  I'm an English-speaker
> in the US who prefers UTF-8, and I don't want any of this rubbish.

yup i bitch to google about such, err, assumpions.

so i'm in oz, so i'm australian.

i'm in france so i'm french.

i'm in sweden so i'm swedish.

NO, just shut up.  i want http://www.google.com in english and they then
tell me to use random URL whatever and it's in english, except the banner
says:

    Google
            Français

i know what i want;  assumption being the mother of all clusterfucks.

call me contrary, but i know what i want.

it's all mike burrows' fault anyway ...

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I think the root of the problem is that in Unix-family operating
> systems (including Plan 9) the shell and utilities have tried to
> serve two different masters, which is always hard.

internationalisation is hard.  forget about french; all those diacritical
marks are just the same as ' in english -- used to replace 'missing'
characters:

    hôpital = hospital 'cos the ô = os

whereas in swedish they have 3 extra real vowels.  sure they have
diacritical marks but they are _real characters_ with a collating
sequence and a nasty set of pronounciation rules.

take iso latin 1:  sure, you have all the chars but it depends on
_where_ you are as:

   Fredrik (listen to me) Juhlin  <laz@strakt.com>

pointed out to me and i had to rethink my internationalisation thoughts.

and, yeah, he was right.

Re: [9fans] Fork: useless and painful?

[Geoff Collyer]

Your point is taken.  I wouldn't object as much to an option to ls
(though ls already has too many options) to print times in the ugly
all-numeric format or just as seconds since the epoch, but to change
the default output format at this late date to the ugly format, with
no obvious way to disable it (I can't see how in a quick reading of
Linux's ls(1)), seems wrong.

To really pick nits, why should setting LANG=en_US.UTF-8 bugger the
sort order and change to all-numeric uglies?  I'm an English-speaker
in the US who prefers UTF-8, and I don't want any of this rubbish.
Actually the all-numeric uglies I sort of understand; I'd never seen
such aversion to four-digit years and month names, despite the
ambiguity of all-numeric dates internationally, until I moved to the
US.  But if I wanted my ls output in `sort -df' order, I'd pipe it
through `sort -df +8'.  These changes are just somebody's favourite
dumb ideas glommed onto a convenient locale.

Re: [9fans] Fork: useless and painful?

[Mike Haertel]

>-rw-rw-r--    1 geoff    geoff       24030 2003-07-01 02:13 .fonts.cache-1
>-rw-rw-r--    1 geoff    geoff       99551 2003-06-25 05:07 FOOFILE
>
>different unhelpful sort order, ugly all-numeric dashed dates and ghod
>only knows what other stupidity.  Luckily, adding LANG=C to your
>.profile defeats this.

While I agree the sort ordering on names is terrible, I'd argue the
"ugly all-numeric dashed dates" are actually more desirable than the
traditional Unix format, because they are more sortable.

With traditional Unix date strings you get into all sorts of ugly
contortions if you want to run them through sort(1).  System V added
a -M option to sort to do grok month names, but it is still unpleasant.

Re: [9fans] Fork: useless and painful?

[Mike Haertel]

>> The only thing I've noticed about it is that they've
>> changed around the default sorting order, and I can't find a way to
>> get the traditional behavior.  Actually, it's really irritating.
>
>I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
>back the way they should be...

I've seen this on Solaris too, so it's hardly a Linux thing.  In
fact, I saw it on Solaris before I ever saw it on Linux.  So by the
time it started popping up on Linux, I knew what to do.  I am pleased
to report that the disease has not yet spread to FreeBSD, at least.

I think the root of the problem is that in Unix-family operating
systems (including Plan 9) the shell and utilities have tried to
serve two different masters, which is always hard.

On one hand, they form a programming language, for which well-defined
behavior is a paramount consideration.  But on the other hand, they
are a user interface.  And people like their interfaces to conform
to their prejudices and comfort zones, rather than having to conform
their behavior to fit a logically minimal interface.

This tension has been in Unix for a long time.  An early example
was the multi-column support in Berkeley "ls" which changed its
behavior depending on whether it thought it was talking to a human
or not.  The recent disease of making all kinds of utilities default
to using locale-specific sorting rather than native machine sorting
is just the latest in a long line of plagues.

The recent Unix/Posix changes are especially ironic and ill-conceived
because they are attempting to change command-line interfaces to
be more "user friendly" at a point in history when all the users
who need "friendliness" are pretty much exclusively using graphical
interfaces anyway.

On the other hand, it would be fair to say that a lot of the power
of Unix as a programming environment comes from developing familiarity,
through routine interactive use, with tools that one can subsequently
incorporate into programs.

So if you can get people to use things interactively you may be
able to turn them into programmers, and that may justify trying to
engineer the command line environment in fuzzy human friendly ways.
But while having logically unnecessary but supposedly human-friendly
features may be reasonable, it's surely NOT an goal that justifies
any design no matter how awful.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> fixed up 300-odd symbols:

symbols?  give me an LA-120 printed VAX stack backtrace and adb and i'm happy.

Re: [9fans] Fork: useless and painful?

[ron minnich]

On Wed, 9 Jul 2003, Vincent van Gelderen wrote:

> On Wednesday 09 July 2003 22:09, andrey mirtchovski wrote:
>
> > and "export LD_DEBUG=all; ls" will show you things you never wanted to know
> >
>
> Incroyable! On my particular machine:
>
> linux:~> (export LD_DEBUG=all; ls /dev/zero) 2>&1 | wc
>    1093    6380   74269

As I said when I first posted this number a year ago, back when it only
fixed up 300-odd symbols:
"masataka ohta, where are you now, you were right all along"

ron

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> I bet you're running a later distribution -- with linux those things
> just grow uncontrollably with time.

debian's apt-get:  it's not apt, but it does get [on your nerves]

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

i quick test for an idiot european is:

    env | egrep 'LANG|LC_'

if LANG != C or LC_ALL != C you have a prize idiot because they
are trusting the interesting instationaliZation (sic) done by americans.

doing that stuff is hard and lunix got it all wrong.

given that i'm feeling 'contrary':  why doesn't the installation process
ask you what sort of keyboard you have?

i can type qwerty, azerty and swedish qwerty but it really is a pain to
have to type qwerty on an azerty keyboard to get to the point where
i can type chars to build the kernel etc that i want.

the 'kbmap' stuff is trivial to install if you can type the chars on the
keyboard.
trying to install it when you don't have a qwerty keyboard, well it's less than
pleasant.

it wouldn't be hard to add and it would make the system more open to
europeans.

i'd do it, mais j'ai d'autres chats à foutter ...

and going back to being 'contrary' your setup had better look pretty much
like what they have at the labs.  this is a semi-criticism, because it's
1127-centric but (thank ...) it's not the 'army of programmers' ...

Re: [9fans] Fork: useless and painful?

[andrey mirtchovski]

On Wed, 9 Jul 2003, Sam wrote:

>
> Bugger.  Your ls must be more optimised. ;)
>

I bet you're running a later distribution -- with linux those things
just grow uncontrollably with time.

expect 'ld' in the kernel come 2.6.0...

Re: [9fans] Fork: useless and painful?

[Geoff Collyer]

The latest bit of whacked behaviour can be seen on RedHat 9, where if
you don't set LANG in your .profile, you get LANG=en_US.UTF-8, which
does this:

: secgw.sec; ls -lA
total 716
-r--r--r--    1 geoff    geoff       92160 2003-06-22 21:36 9wm-1.2.tar
lrwxrwxrwx    1 geoff    geoff          11 2003-06-22 20:03 .acrorc -> lib/.acrorc
lrwxrwxrwx    1 geoff    geoff           9 2003-06-22 20:18 .bash_history -> /dev/null
drwxr-xr-x    4 geoff    geoff        4096 2003-06-22 16:13 bin
-rw-------    1 geoff    geoff          16 2003-06-26 23:09 .esd_auth
lrwxrwxrwx    1 geoff    geoff          15 2003-06-22 20:03 .find.codes -> lib/.find.codes
-rw-rw-r--    1 geoff    geoff       24030 2003-07-01 02:13 .fonts.cache-1
-rw-rw-r--    1 geoff    geoff       99551 2003-06-25 05:07 FOOFILE
-rw-rw-r--    1 geoff    geoff      315392 2003-06-25 05:49 FOOFILE2
-rw-rw-r--    1 geoff    geoff         126 2003-06-25 05:56 FOOFILE3

different unhelpful sort order, ugly all-numeric dashed dates and ghod
only knows what other stupidity.  Luckily, adding LANG=C to your
.profile defeats this.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Incroyable!

quelle putain de connerie!!

Re: [9fans] Fork: useless and painful?

[Vincent van Gelderen]

On Wednesday 09 July 2003 22:09, andrey mirtchovski wrote:

> and "export LD_DEBUG=all; ls" will show you things you never wanted to know
>

Incroyable! On my particular machine:

linux:~> (export LD_DEBUG=all; ls /dev/zero) 2>&1 | wc
   1093    6380   74269

Regards,
Vincent van Gelderen

Re: [9fans] Fork: useless and painful?

[Derek Fawcus]

On Wed, Jul 09, 2003 at 02:09:17PM -0600, andrey mirtchovski wrote:
> On Wed, 9 Jul 2003, Derek Fawcus wrote:
>
> > I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
> > back the way they should be...
> >
>
> and "export LD_DEBUG=all; ls" will show you things you never wanted to know

and those are the reasons I've replaced the my ls with the one from embutils

Re: [9fans] Fork: useless and painful?

[Dan Cross]

"boyd, rounin" <boyd@insultant.net> writes:
>
> >  Actually, it's really irritating.
>
> well there is that.  and the ls | mc default and the colours based on file
> type ...

Oh, I turned that junk off.  Ls is aliased to ls -1A and lc is aliased to
ls | mc, as it should be (using my Unix version of mc).

> oh, yeah, don't forget the mmap() implementation of cat -- try that on a pipe
> ...

Yeah, that is dumb.

> now, don't get me all contrary ...

:-)

I still find Lunix horrible, but at least it's tolerable for the most
part at this point.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[Sam]

> Incroyable! On my particular machine:
>
> linux:~> (export LD_DEBUG=all; ls /dev/zero) 2>&1 | wc
>    1093    6380   74269

$ LD_DEBUG=all ls /dev/zero 2>&1 | wc
   1388    8913   94822
$

Bugger.  Your ls must be more optimised. ;)

Sam

Re: [9fans] Fork: useless and painful?

[Dan Cross]

Derek Fawcus <dfawcus@cisco.com> writes:
>
> On Wed, Jul 09, 2003 at 03:45:29PM -0400, Dan Cross wrote:
> > The only thing I've noticed about it is that they've
> > changed around the default sorting order, and I can't find a way to
> > get the traditional behavior.  Actually, it's really irritating.
>
> I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
> back the way they should be...

Ahh....  Thanks to you and Vic for telling me this.  I feel much more
at home now.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

>  Actually, it's really irritating.

well there is that.  and the ls | mc default and the colours based on file type
...

explain to my why:

    ls

and:

    ls | cat

give diffferent visual [human readable] outputs?

oh, yeah, don't forget the mmap() implementation of cat -- try that on a pipe
...

now, don't get me all contrary ...

Re: [9fans] Fork: useless and painful?

[andrey mirtchovski]

On Wed, 9 Jul 2003, Derek Fawcus wrote:

> I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
> back the way they should be...
>

and "export LD_DEBUG=all; ls" will show you things you never wanted to know

:)

Re: [9fans] Fork: useless and painful?

[Derek Fawcus]

On Wed, Jul 09, 2003 at 03:45:29PM -0400, Dan Cross wrote:
> The only thing I've noticed about it is that they've
> changed around the default sorting order, and I can't find a way to
> get the traditional behavior.  Actually, it's really irritating.

I find it really bloody annoying,  however 'LC_ALL=C ls' put's things
back the way they should be...

Re: [9fans] Fork: useless and painful?

[Dan Cross]

> i tend to agree.  look what they did to ls(1) on lunix ...

Okay, this *raises* the question (Hi, Matt!): What *did* they do to
ls on lunix?  The only thing I've noticed about it is that they've
changed around the default sorting order, and I can't find a way to
get the traditional behavior.  Actually, it's really irritating.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> ... But all the published programs that people see use pthreads,
> which is an anti-unix design.

pthreads?  yeah, i wrote some of that once -- ghastly.  all those
extra characters to type and if you get it wrong, well your code
breaks.

i think rob said once that:

    concurrent [thread] programming is beyond the capabilities of
    most programmers.

i tend to agree.  look what they did to ls(1) on lunix ...

Re: [9fans] Fork: useless and painful?

[boyd, rounin]

> Maybe it's just me, but I've always liked fork.

yeah, i kinda like it too.

on the one had we have fork() -- zero arguments.

then, we have on NT CreateProcess() which takes 10 arguments and two of
those are structs (iirc).  now the only _feature_ here is that all the args and
and values in the structs can be either 0 or NULL;  write once, copy and paste
everywhere.

maybe it's just me.  if 10 was 0?

Re: [9fans] Fork: useless and painful?

[Dan Cross]

> I'm hearing the claim that fork is "useless and painful" (from an IBM K42
> guy).
>
> Maybe it's just me, but I've always liked fork.

> Am I nuts?

Well, for what?  I find fork useful for all sorts of things  For
running another program, I never did quite figure out why there wasn't
a `spawn' library function that did the dance for you; I could see
fork() looking like an unnecessary extra step if that's all you ever
saw it do, but then I'd just point to pipelines of commands and the
simplicity of `backgrounding' a process as a counter example.

And, of course, rfork() is pretty cool, as Scott pointed out.

	- Dan C.

Re: [9fans] Fork: useless and painful?

[Scott Schwartz]

Ron says:
| I'm hearing the claim that fork is "useless and painful" (from an IBM K42
| guy).
|
| Maybe it's just me, but I've always liked fork.
|
| Am I nuts?

Not at all.  But all the published programs that people see use pthreads,
which is an anti-unix design.  If you want to change people's minds,
you have to show them programs that use rfork effectively.  (Linux has
cleverly engineered clone so that it can't be used directly, which feeds
the idea that pthreads are the right thing.)

[9fans] Fork: useless and painful?

[ron minnich]

I'm hearing the claim that fork is "useless and painful" (from an IBM K42
guy).

Maybe it's just me, but I've always liked fork.

Am I nuts?

ron