Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Unidentified subject! (Quinn Dunkan's zsh speculations)
- X-seq: zsh-users 1080
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Quinn Dunkan <quinn@xxxxxxxxxxxxxxxxxxxxx>, zsh-users@xxxxxxxxxxxxxxx
- Subject: Re: Unidentified subject! (Quinn Dunkan's zsh speculations)
- Date: Sat, 11 Oct 1997 02:10:38 -0700
- In-reply-to: <199710110705.AAA01332@xxxxxxxxxxxxxxxx>
- References: <199710110705.AAA01332@xxxxxxxxxxxxxxxx>
On Oct 11, 12:05am, Quinn Dunkan wrote:
} Subject: Unidentified subject!
}
} I'm not sure why people are reproducing ls, cp, etc. as builtins, though.
To avoid fork+exec. Aside from avoiding such things as running out of
process table space, it also means that with a statically linked copy of
the shell, you can do emergency repair work even if for some reason your
dynamic linker/loader is hosed. Without the shell builtins, you'd need
static-linked copies of most of the programs in /bin.
} BTW, what is the use of the > and < redirections? It seems they could be
} replaced with `re file | cmd' and `cmd | wr file' (read and write are already
} taken). It would be more to type, but the current distinction shells make
} between pipes and redirections has always been strange to me. Does the shell
} really need a way to read and write directly to files?
You can seek forwards and backwards on a true file descriptor; you can't
seek on a pipe. > and < aren't for the shell's benefit, they're to
provide the right kind of descriptor to the command that eventually gets
them as stdin/out/err. Believe it or not, some programs do require that
their stdin or stdout be seekable, and others behave differently and/or
work more efficiently when they're able to seek.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author