I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
I have no actual information about the lantern character, but
a tapered "storm lantern" would be far down my list of guesses.
The tapered chmney would much more likely be called a "lamp",
for it's a standard shape for the oil (kerosene) lamps
that everyone had before electricity.
My top guess would be a carriage lantern with a Japanese
garden ornament as a distant second. The carriage lantern
would be an unfilled circle superimposed on a vertical
rectangle, filled or unfilled. The rectangle might be
simplified to two (interrupted) vertical sides.
An alternate form of lantern would be a side view of
a carriage (or picture-projection) lantern, schematized
as a box, with a flaring projection to the right--an
icon for shining light on a subject, also interpretable
as a movie camera.
A Japanese lantern would be tripartite: cap, body, and
feet.
Do any of these possibilities ring a bell?
Doug
> Message: 1
> Date: Thu, 27 Jul 2017 11:58:38 -0400
> From: Random832 <random832(a)fastmail.com>
> To: tuhs(a)minnie.tuhs.org
> Subject: [TUHS] Anyone know what a LANTERN is?
> Message-ID:
> <1501171118.69633.1054588920.11864815(a)webmail.messagingengine.com>
> Content-Type: text/plain; charset="utf-8"
>
> There is a character in the terminfo/curses alternate character set,
> ACS_LANTERN, which is mapped to "i" in the VT100 alternate grapical
> character set. This character is, in fact, on a real VT100/VT220 (and
> therefore in most modern terminal emulators that support the full ACS),
> "VT" (in 'control character picture' format, along with HT FF CR LF NL).
> The ASCII mapping uses "#", and some CP437/etc mappings map it to the
> double box drawing intersection character.
>
> Was there ever a real 'lantern' character? The manpage mentions "some
> characters from the AT&T 4410v1 added". What did it look like?
There's two references in the termcap manpages:
http://invisible-island.net/ncurses/man/terminfo.5.html
and
http://invisible-island.net/ncurses/man/curs_add_wch.3x.html
The second link mentions that the AT&T 4410 terminal added this glyph in the location of the VT100 VT glyph. Apparently what it looked like is lost, unless someone finds a detailed 4410 manual (or has a working one in the attic).
There is a character in the terminfo/curses alternate character set,
ACS_LANTERN, which is mapped to "i" in the VT100 alternate grapical
character set. This character is, in fact, on a real VT100/VT220 (and
therefore in most modern terminal emulators that support the full ACS),
"VT" (in 'control character picture' format, along with HT FF CR LF NL).
The ASCII mapping uses "#", and some CP437/etc mappings map it to the
double box drawing intersection character.
Was there ever a real 'lantern' character? The manpage mentions "some
characters from the AT&T 4410v1 added". What did it look like?
That is such a great shot!
Since we are on the topic of photos…
I’ve been shooting portraits of some of these same people as part of a larger photo project called Faces of Open Source.
If anyone is interested in taking a look, here they are: http://facesofopensource.com
-P-
—
Peter Adams Photography | web: http://www.peteradamsphoto.com | Instagram/twitter: @peteradamsphoto @facesopensource
> On Jul 19, 2017, at 7:00 PM, tuhs-request(a)minnie.tuhs.org wrote:
>
> Send TUHS mailing list submissions to
> tuhs(a)minnie.tuhs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> or, via email, send a message with subject or body 'help' to
> tuhs-request(a)minnie.tuhs.org
>
> You can reach the person managing the list at
> tuhs-owner(a)minnie.tuhs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TUHS digest..."
> Today's Topics:
>
> 1. Photo of some Unix greats (Dave Horsfall)
> 2. Re: Photo of some Unix greats (Larry McVoy)
> 3. Re: Photo of some Unix greats (Dan Cross)
>
> From: Dave Horsfall <dave(a)horsfall.org>
> Subject: [TUHS] Photo of some Unix greats
> Date: July 19, 2017 at 3:48:48 PM PDT
> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
>
>
> https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg
>
> Dennis Ritchie, Steve Bellovin, Eric Allman, Andrew Hume (I know him), Don Seeley, Mike Karels, Clem Cole...
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>
>
>
>
> From: Larry McVoy <lm(a)mcvoy.com>
> Subject: Re: [TUHS] Photo of some Unix greats
> Date: July 19, 2017 at 4:35:05 PM PDT
> To: Dave Horsfall <dave(a)horsfall.org>
> Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
>
>
> It's a cool picture, thanks. Brings back lots of memories and makes me
> hate being younger than that crowd, would have loved to have been there.
> I was just far enough along at that point to have a job sys admining some
> of Clem's work products, 3 Masscomps. Think I was a junior in college.
>
> Great picture, good people.
>
> On Thu, Jul 20, 2017 at 08:48:48AM +1000, Dave Horsfall wrote:
>> https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg
>>
>> Dennis Ritchie, Steve Bellovin, Eric Allman, Andrew Hume (I know him), Don
>> Seeley, Mike Karels, Clem Cole...
>>
>> --
>> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>
> --
> ---
> Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
>
>
>
>
> From: Dan Cross <crossd(a)gmail.com>
> Subject: Re: [TUHS] Photo of some Unix greats
> Date: July 19, 2017 at 6:22:47 PM PDT
> To: Dave Horsfall <dave(a)horsfall.org>
> Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
>
>
> I like how Andrew Hume is defying the weather. Like a boss.
>
> On Wed, Jul 19, 2017 at 6:48 PM, Dave Horsfall <dave(a)horsfall.org <mailto:dave@horsfall.org>> wrote:
> https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg <https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg>
>
> Dennis Ritchie, Steve Bellovin, Eric Allman, Andrew Hume (I know him), Don Seeley, Mike Karels, Clem Cole...
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS(a)minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
On 2017-07-09 23:44, ron minnich <rminnich(a)gmail.com> wrote:
> On Sun, Jul 9, 2017 at 2:29 PM Dave Horsfall <dave(a)horsfall.org> wrote:
>>
>> I vaguely remember something like "PIP *.TXT *.OLD" to rename files (the
>> "*" was interpreted by the command itself, not the interpreter).
Well, that would not rename files, but copy them and at the same time
changing their names. But you could also do renaming in a similar way,
but usually it would require a switch to PIP telling it that you wanted
the files renamed, and not copied.
Also, the syntax of PIP, and the order of arguments is a bit different.
At least the versions I can remember right now, it would be:
PIP *.OLD=*.TXT
to copy, and
PIP *.OLD/RE=*.TXT
to rename.
And yes, it is the program who process the wildcard expansions, and not
the command interpreter. Which is why commands like the ones above
worked. This is one of those classical examples you get to when
comparing Unix with DEC OSes about wildcarding, and the effects the
different ways they are done have on the result.
(In Unix, you can't do such a mass copy and rename in the same way.)
> All the DEC-10 and 11 operating systems I used had that wildcard, as well
> as IIRC even the PDP-8, maybe someone can confirm the -8.
Yes. It's the same on the OSes I've used on PDP-8s as well.
I would say that the globbing in Unix have much less to do with regular
expressions and much more to do with trying to mimic what DEC was doing
in their OSes.
> It would have been nice had RE's been the standard way to glob files, but,
> that said, when I mention .*\.c to people instead of *.c they don't much
> like it.
In a way, it would have made more sense to just use standard RE's for
globbing, but that didn't happen. And like I said, I suspect it was
because DEC OSes did it this way, and Unix just mimicked it. Same I
guess with the convention of '.' to separate filename from type. Even
though it's less pervasive in Unix than in DEC systems.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Glob was an an accident. When Ken and Dennis wanted to put wildcards
(an anachronistic word--it wasn't used in the Unix lab at the time)
into the shell, there wasn't room, so they came up with the clever hack
of calling another process to do the work.
I have always understood that glob meant global because commands like
rm *
would be applied to every file in a directory. A relationship to ed's
g command was clear, but not primary in my mind.
One curious fact is that from day one the word hase been pronounced glob,
not globe. (By contrast, creat has been variously pronounced cree-at
and create.) It is also interesting to speculate on whether there would
be a glob library routine in Linux had glob only been an identifier in
sh.c rather than an entry in /bin.
I believe the simple * was borrowed from somewhere else. If the g command
had been the driving model, glob would probably have had ? and ?*, not
? and *. (It couldn't use ed's . because . was ubiquitous in file names.)
My etymology is somewhat different from Steve's. But I never asked the
originator(s). Steve, did you?
Doug
On 7/9/17, ron minnich <rminnich(a)gmail.com> wrote:
>>
> All the DEC-10 and 11 operating systems I used had that wildcard, as well
> as IIRC even the PDP-8, maybe someone can confirm the -8.
>
> It would have been nice had RE's been the standard way to glob files, but,
> that said, when I mention .*\.c to people instead of *.c they don't much
> like it.
So when were REs first designed and implemented? I would imagine that
they came about as a way to extend the old '*' and '?' wildcard
syntax, but that is only a guess.
-Paul W.
