On Dec 29, 2021, at 8:01 AM, Bakul Shah <bakul(a)iitbombay.org> wrote:
> On Dec 29, 2021, at 7:18 AM, Clem Cole <clemc(a)ccc.com> wrote:
>>
>> Think about the UNIX FS and the link system call. How is mv implemented? You link the file to the new directory and the unlink it from the old one. But a directory file can not be in two directories at the same time as the .. link would fail.
>
> Don’t see why linking a dir in two places is a problem.
To expand on this a bit, the “cd ..” case can be handled by not storing a ..
link in a dir. in the first place! Store the $PWD path in the u struct. Then
cd .. would simply lop off the last component, if one exists. Thus .. takes
you back only on the path you used! This also takes care of the issue with
symlinks (& does what csh did in user code).
The first specific mention of moving directories in Research is in
v10, but I'm sure that was implemented considerably earlier. The only
things special about moving a directory were that it needed root
privilege and checked against moving a directory into itself. As with
ordinary files, copying (with loss of hard links) happened only when
moving between different file systems. As far as I know, no atomicity
precautions were taken.
The core system of svr2 distributed by ATT for the 3b2-400 doesn't come
with manpages installed. Does anybody know of a set of manpages for SVR2
that can be installed into the system? It's not the end of the world, if
not... the user guide is available as a pdf, but it'd be handy to have
man on the system.
Will
Is it possible to use echo to send a vt-100 escape sequence in v6/v7/sysvr2?
I can write a c program to clear the screen and go home in sysvr2:
#define ASCII_ESC 27
main()
{
printf( "%c[2J", ASCII_ESC );
printf( "%c[H", ASCII_ESC );
}
and it works fine. I can type the escape sequences in as well, but I'd
just as soon write a shell script with an echo '[[2J;[[H' or something
similar without having to compile a clear command. Is it possible and
what do I need to know :)?.
Thanks,
Will
> From: Will Senn
> anything similar to modern behavior when handling the delete/backspace
> key where the character is deleted from the input and rubbed out? The
> default, like in v6/v7 for erase and kill is # and @. I can live with
> this, if I can't get it to do the rubout, because at least you can see
> the # in the input
I use ASCII 'backspace' (^H) on my V6, and it 'sort of' works; it doesn't
erase the deleted character on the screen, but if one then types corrected
characters, they overlay the deleted ones, leaving the corrected input. That
should work on everything later than V6.
The MIT PWB1 tty handler (link in a prior message) not only supported a 'kill
line' (we generally used '^U') which actually visibly deleted the old line
contents (on screen terminals, of course; on printing terminals you're
stuck), it also had suppport for '^R' (re-type line) and some other stuff.
Noel
Did svr2 have anything similar to modern behavior when handling the
delete/backspace key where the character is deleted from the input and
rubbed out? The default, like in v6/v7 for erase and kill is # and @. I
can live with this, if I can't get it to do the rubout, because at least
you can see the # in the input, but if I can figure out how to get it to
rubout the last character, I'd map erase to DEL, which I believe to be
^U (but since it's invisible, it's confusing when it doesn't rubout).
Will
All,
Are there any bootable media available for any SVR 2 systems available
online? Or are they all under IP lock and key? If so, what's the closest
system that is available to get a feel for that variety of OS?
Happy holidays, folks.
Will
Hi all, I received an e-mail looking for the ksh-88 source code. A quick
search for it on-line doesn't reveal it. Does anybody have a copy?
Cheers, Warren
Original e-mail:
I recently built a PiDP11 and have been enjoying going back in time
to 2.11BSD.. I was at UC Davis in the the early 1980's and we had
a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to
David Korn and he sent us the source for KSH -- this would have been
in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix,
and some other variants that used K&R C. It may have been what was
later called ksh88. I wish I still had the files from then..
I was wondering if you might know if there's an older version like this
or one that's been ported for 2.11BSD?
Many thanks,
Joe
Hey Warren,
First and foremost; Thank you so much for maintaining this mailing list, and for including me within the subscribers list. I find myself intrigued by some of the topics that transfer over to the “COFF” mailing list. Could you include me on that mailing list as well?
Peace.
Thomas Paulsen:
bash is clearly more advanced. ksh is retro computing.
====
Shell wars are, in the end, no more interesting than editor wars.
I use bash on Linux systems because it's the least-poorly
supported of the Bourne-family shells, besides which bash
is there by default. Ksh isn't.
I use ksh on OpenBSD systems because it's the least-poorly
supported of the Bourne-family shells, besides which kh
is there by default. Bash isn't.
I don't actually care for most of the extra crap in either
of those shells. I don't want my shell to do line editing
or auto-completion, and I find the csh-derived history
mechanisms more annoying than useful so I turn them off
too. To my mind, the Research 10/e sh had it about right,
including the simple way functions were exported and the
whatis built-in that told you whether something was a
variable or a shell function or an external executable,
and printed the first two in forms easily edited on the
screen and re-used.
Terminal programs that don't let you easily edit input
or output from the screen and re-send it, and programs
that abet them by spouting gratuitous ANSI control
sequences: now THAT's what I call retro-computing.
Probably further discussion of any of this belongs in
COFF.
Norman Wilson
Toronto ON
