> From: Bakul Shah
> In hindsight Algol68 may have been the last committee designed language
> that was good.
I do not grant your basic assertion. Hoare had it right: "ALGOL 60 [was] a
language so far ahead of its time that it was not only an improvement on its
predecessors but also on nearly all its successors." That would definitely
include Algol68, which was a classic committee-designed nightmare.
Noel
Dennis added setjmp() and longjmp() so the shell could handle errors in a reasonable way.
There are two places where setjmp was used in the original shell (7th edition) code as I recall.Â
Both at the top level
in main.c.
The idea came from Algol68 but I do not know where it was originally invented. longjmp() was used
in the "exitsh"
function that got called on the exit command, default trap routine and a fault with no trap set.
It was also used when executing a subshell to avoid a fork and exec. In this case the setjmp() was
at top level
in the initial sh setup.
Hope this makes sense. But these were two different uses. One for error recovery and one to reset
the execution environment
back to initial state.
Steve
> From: Larry McVoy
> If there are no commercial users of that source base, you have a chance
When was the last VAX sold? Maybe the VAX version people would be willing to
let go of.
Noel
> From: Ken Unix
> I have mknod but need the (c,b) major/minor numbers for /dev/lp
It looks like SysV still has conf.c; you're looking for 'cdevsw'.
Noel
> In hindsight Algol68 may have been the last committee designed
> language that was good.
The committee itself fractured over the design. Dissenters who thought
it was far too complex upped stakes and formed WG2.3, which pointedly
concentrated on program design, not language.
Doug
Hi.
I am trying to figure out how to create a device /dev for lp.
I have mknod but need the (c,b) major/minor numbers for /dev/lp
/etc/mknod name c | b major minor
I do have the required software to run lp. I have read through the
docs I have but no luck.
Thanks
Ken
--
WWL 📚
> From: Warner Losh
> In C I use it all the time to do goto err for common error recovery
> because C doesn't have anything better.
That's because C doesn't have 'conditions'. (Apparently, from the following
posts, most people here are unfamiliar with them. Too bad, they are a great
idea. OK summary here:
http://gunkies.org/wiki/Condition_handler
for those who are unfamiliar with the idea.)
I was at one point writing a compiler using a recursive descent parser, and
decided the code would be a lot simpler/cleaner if I had them. (If, for
example, one discovers discovers an un-expected 'end of file', there can be
an extremely large number of procedure invocations in between where that is
discovered, and where it is desirable to handle it. So every possible
intervening procedure would have to have an 'unexpected EOF' return value,
one would have to write code in every possible intervening procedure to
_handle_ an 'unexpected EOF' return value, etc.)'
(Yes, I could have used setjmp/longjmp; those are effectively a limited
version of condition handlers.)
Since C has a stack, it was relatively easy to implement, without any compiler
support: on() became a macro for 'if _on("condition_name")'; _on() was a
partially-assembler procedure which i) stacked the handler (I forget where I
put it; I may have created a special 'condition stack', to avoid too many
changes to the main C stack), and ii) patched the calling procedure's return
point to jump to some code that unstacked the handler, and iii) returned
'false'. If the condition occurred, a return from _on() was simulated,
returning 'true', etc.
So the code had things like:
on ("unexpected EOF") {
code to deal with it
}
With no compiler support, it added a tiny bit of overhead
(stacking/unstacking conditions), but not too bad.
John Wroclawski and someone implemented a very similar thing
entirely in C; IIRC it was built on top of setjmp/longjmp. I don't
recall how it dealt with un-stacking handlers on exit (which mine
did silently).
Noel
I wonder if Pink Floyd's Summer68 maybe refers to this.
Other than that i am addicted and could not live without it.
The other (terrible) song is from 1984 (east southern US).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Starting this in TUHS due to UNIX relevance, but with the heavy disclaimer this should quickly diverge to COFF if it drifts into foreign waters.
I've gotten to reading about 5ESS lately, and it seems there are many in use still today. I found myself wondering what the evolution has looked like as far as computing hardware and operating systems involved. DMERT ran on the 3B-20D supporting the 5ESS systems in the early 80s, at the same time that UNIX 4.x was making rounds on the 3B-20S.
A 5ESS manual from 2001[1] mentions UNIX RTR (Real-Time Reliable) of the DMERT lineage. Wikipedia[2] suggests 5ESS is still very much in use and mentions more modern systems like VCDX; its "Sun Microsystems SPARC workstation runs the UNIX-based Solaris (operating system) that executes a 3B20/21D processor MERT OS emulation system." This sounds like the Lucent 3B20 emulator.
Is there still a line of UNIX RTR/DMERT being maintained to this day? Or are users left with other avenues to keep their hardware updated if necessary?
[1] - https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/235600510_V1_5…
[2] - https://en.wikipedia.org/wiki/5ESS_Switching_System
- Matt G.
On SCO UNIX 3.2V4 you indeed have local virtual consoles moving from one to
another using the function keys. Worked from F1 to F12, but how often you
could login would depend on your license. Of course all still character
based, and depending on your TERM setting.
--
The more I learn the better I understand I know nothing.