[TUHS] Dash options

[TUHS] Dash options

[Noel Chiappa]

    > From: Charles Anthony

    > Entry points are usually defined as "foo$bar", where "foo" is the
    > segment name, and "bar" an entry point in the segment symbol table. I
    > believe that the degerate case of "foo$" is treated as "foo$foo" by the
    > shell.

So I'm curious about how this, and additional names, interact. (For those who
aren't familiar with Multics, a segment [file, sort of] can have multiple
names. This is sort of like 'hard links' in Unix, except that in Multics one
name, the "primary name" is very slightly preeminent. See here:

  http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout

page 2-5, for more, if you're interested.)

So if I have a segment with primary name 'foo', and additional names 'bar' and
'zap', and I say 'zap' to the Multics shell, I assume it does a call to
zap$zap, which finds the segment with the primary name 'foo', and calls the
'zap' entry therein?


    > Multics rulez; UNIX droolz

Dude, you clearly have Very Large brass ones to send that to this list! :-)

      Noel

[TUHS] Dash options

[Charles Anthony]

On Wed, Nov 29, 2017 at 6:03 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Charles Anthony
>
>     > Entry points are usually defined as "foo$bar", where "foo" is the
>     > segment name, and "bar" an entry point in the segment symbol table. I
>     > believe that the degerate case of "foo$" is treated as "foo$foo" by
> the
>     > shell.
>
> So I'm curious about how this, and additional names, interact. (For those
> who
> aren't familiar with Multics, a segment [file, sort of] can have multiple
> names. This is sort of like 'hard links' in Unix, except that in Multics
> one
> name, the "primary name" is very slightly preeminent. See here:
>
>   http://web.mit.edu/multics-history/source/Multics/mdds/mdd006.compout
>
> page 2-5, for more, if you're interested.)
>
>
They are also different in an important way: the additional name is part of
the segment, not of the directory. If the segment is moved to a different
directory, the names move with it.


> So if I have a segment with primary name 'foo', and additional names 'bar'
> and
> 'zap', and I say 'zap' to the Multics shell, I assume it does a call to
> zap$zap, which finds the segment with the primary name 'foo', and calls the
> 'zap' entry therein?
>
> Turns out that it does (I thought it didn't, but I checked first).

Multics has a search path mechanism (like $PATH); the directories listed
therein are searched for a matching segment name or additional name.

For the hello$world example, the command "an hello world" would add the
name "world" to the "hello" segment and then the command "world" would
become equivalent to "hello$world".

For the case of "bound" segments, (several object segments linked together
in a single segment, and the intersegment links "pre-snapped", the binder
control file (similar to ld's ifile) would list the entry points that were
to be made externally visible, and the binder automatically adds those
names to the the bound segment:

Eg, teco lines in "bound_teco"; the "ls" command sees that "teco" is a name
of the "bound_teco" segment.

ls >tools>teco

Segments = 1, Lengths = 9.

re     9  bound_teco_
          teco_ssd
          teco
          teco_get_macro_
          teco_error
          teco_error_mode
          get_temp_seg_
          assign_temp_seg_id_
          release_temp_seg_
          release_temp_segs_all_
          get_seg_ptr_
          get_seg_ptr_arg_
          get_seg_ptr_full_path_
          get_seg_ptr_search_
          release_seg_ptr_




>
>     > Multics rulez; UNIX droolz
>
> Dude, you clearly have Very Large brass ones to send that to this list! :-)
>
>
Thank you (I think). Should be a nice change from the Microsoft fan boys,
tho.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171129/891bef77/attachment.html>

[TUHS] Dash options

[Doug McIlroy]

Early on, when multics was understood to have
one big, segemented address space, it was expected
that PL/I name qualification ($) would serve to address
segments. I do not know whether that idea was
actually implemented.

Doug

[TUHS] Dash options

[George Michaelson]

I had an interesting conversation with people years gone by about the
logistical benefits or hindrances of being explicit about device in
the path, which vax/vms did sys$system: type statements. I'm now fully
acculturated to not want it, but in a world where the operating system
did less for you, explicitly flagging the device a la PIP (yes,
Decisms) had some basis in reality: you said what you expected the
device level events were, to achieve the outcome.

So distinguishing device semantically, for some people, reductionists,
worked. masking the device, by intruding (sorry, bad word) a path as a
blinding, anonymous namespace, with device inferred.. that was an
inferential leap. I think newcastle connection went further embedding
/.../ as a denotation of network-jump to move to other devices. WIsh
that had taken off, fitted the . and .. semantic model nicely inside
the /path/to/thing

I used at least one OS which had path.to.thing via dots, and rather
oddly, only DESCENT. you couldn't walk backwards. so directory descent
in the JCL was possible, but to go up one level you had to go down
from the top, N-1 path elements from position N. Bizarre, suggesting
it wasn't a doubly linked list?

switches, flags, options, three words for the same thing...

a lot of this stuff was being defined in a time when we still used
languages where file IO was bound to IO numbers and about batch entry
bindings where the 1..n range of devices was literally which "thing"
fed the input or output stream, not just an ioctl() convenience
binding. I never entirely got why in my fortran I was using IO 2 so
much. what happened to 0 and 1?

or the pascal file pointer. what an odd construct that was looking
backwards from more abstracted file position, but then think what
seek() is actually doing..

-G

On Wed, Nov 29, 2017 at 11:23 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Early on, when multics was understood to have
> one big, segemented address space, it was expected
> that PL/I name qualification ($) would serve to address
> segments. I do not know whether that idea was
> actually implemented.
>
> Doug

[TUHS] Dash options

[Charles Anthony]

On Tue, Nov 28, 2017 at 5:23 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Early on, when multics was understood to have
> one big, segemented address space, it was expected
> that PL/I name qualification ($) would serve to address
> segments. I do not know whether that idea was
> actually implemented.
>
>
If I understand you correctly, approximately yes.

Entry points are usually defined as "foo$bar", where "foo" is the segment
name, and "bar" an entry point in the segment symbol table. I believe that
the degerate case of "foo$" is treated as "foo$foo" by the shell.

In the following example, the segment name is "hello", the entry point
"world".


*edm hello.pl1*
Segment not found.
Input.
*world: procedure options(main);*
*  dcl sysprint file output print stream;*
*  put list ("Multics rulez; UNIX droolz");*
*  put skip;*
*end world;*
*.*
Edit.
*w*
*q*
r 16:45 0.050 3

*pl1 hello*
PL/1 33e

r 16:45 0.128 36

*hello$world*
Multics rulez; UNIX droolz
r 16:45 0.033 23


-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/51493d01/attachment.html>

[TUHS] Dash options

[Paul Ruizendaal]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]


> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski at gmail.com>
> wrote:
> 
>> MS/DOS patterned its command line
>> ​ ​
>> syntax after RT-11 and inherited the slash as a command option
>> introduction from there.
> 
> ​Minor correction...   To do a CDC style patient zero history ;-) RT11 took
> it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
> PC-DOS ney MS/DOS took it from CP/M.

I think Gary Kildall was very much into the PDP-8 when teaching at the
Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler
for instance). Can't find the link now, but I read somewhere that his
work with the 8008 and 8080 was guided by the idea of having a PDP-8 like
machine in his home office. For CP/M's command syntax RT11 probably did
not come into it. I just had a quick glance through the CP/M 1.4 - 2.2
manuals, and I did not see slash options (or any other option character).

Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls
were done such that converting existing 8080 CP/M code with Intel's source
level 8080-to-8086 asm converter would generate the correct code. The FAT
file system was modeled after the one used by MS Disk BASIC for the 8086.
Not sure where the QDOS command line came from, other than CP/M. MS did a
lot of its early development on a PDP-10: perhaps that was an inspiration
too.

Sorry for getting off-Unix-topic...

[TUHS] Dash options

[Noel Chiappa]

    > Multics had some kind of `attach' and `detach' of I/O streams, well
    > known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
    > with it meant `>' was earmarked early on.

According to "The Evolution of the Unix Timesharing System", full path names
arrived later than I/O redirection, so by they time they needed a separator,
'>' and '<' were gone. '/' also has the advantage of being a non-shift
character!

	Noel

PS: Re-reading that, I see that early Unix did not have an exec() call (as I
was just discussing); it was done in user mode, with normal read and write
calls.

[TUHS] Dash options

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

dash as switches were always explained to me as from Multics.   Having used
DEC systems, Univax and IBM systems originally with cards and ASR33s, I was
not yet stubborn enough to see value one way or the other (the links in
ROMs in my fingers were not yet programmed).  By the time I left CMU and
the glass tty was all I was willing to use.  I had become a UNIX/C person
more than anything else, so slashes as switches (and upper case and case
folding) had become annoying and just seemed wrong.

On Tue, Nov 28, 2017 at 8:19 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> According to "The Evolution of the Unix Timesharing System", full path
> names
> arrived later than I/O redirection, so by they time they needed a
> separator,
> '>' and '<' were gone.

​That was the impression I had had and I admit I think I must have either
assumed it, heard it in conversation, or maybe read it at some point in
this paper.   Cann't say when I started to think same, but I came to UNIX
in Fifth and Sixth so, they were already there.  I was just learning the
'UNIX way' at the time.​   I guess because I was using so many
different systems at the time, I was more willing to accept every dialect
had its way of doing things.   As Greg points out EXEC-8 was hardly
anything like TSS/360 and learned them together.   Same as TOPS/TWINEX and
eventually VMS.

Funny, things is I left those other systems and then was forced to come
back to them, first RT11 and then NOS/KRONOS and then VMS and I remember
grumbling.  By then the ROMs had been forced in my muscle memory.

'/' also has the advantage of being a non-shift
> ​ ​
> character!
>
​Hmm, so was dot, which is what TSS and MTS used.​  DEC was using it as the
<base>.<ext> separator, but I think Ken could have used it as easily at the
time since the idea of <ext> and exposing semantics of what the file was in
the name was foreign to UNIX (although was used in other systems as we
know).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/9a5d41a4/attachment.html>

[TUHS] Dash options

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Tue, 28 Nov 2017, Clem Cole wrote:

> ​Hmm, so was dot, which is what TSS and MTS used.​  DEC was using it as 
> the <base>.<ext> separator, but I think Ken could have used it as easily 
> at the time since the idea of <ext> and exposing semantics of what the 
> file was in the name was foreign to UNIX (although was used in other 
> systems as we know).

OS/360's JCL used "." (partitioned datasets?) such as SYS1.WATFIV.blah and 
so on.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Dash options

[Jon Steinhart]

Does anybody know the history of dash options?  Were they
a UNIX thing or did UNIX borrow them from something earlier?

Jon

[TUHS] Dash options

[Dave Horsfall]

On Mon, 27 Nov 2017, Jon Steinhart wrote:

> Does anybody know the history of dash options?  Were they a UNIX thing 
> or did UNIX borrow them from something earlier?

An equivalent question would be why "/" was chosen as the directory 
separator, as it was commonly used for flags.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Dash options

[Andrew Warkentin]

On 11/27/17, Dave Horsfall <dave at horsfall.org> wrote:
> On Mon, 27 Nov 2017, Jon Steinhart wrote:
>
>> Does anybody know the history of dash options?  Were they a UNIX thing
>> or did UNIX borrow them from something earlier?
>
> An equivalent question would be why "/" was chosen as the directory
> separator, as it was commonly used for flags.
>

Multics had dash options, so that's presumably where Unix got them
from. I believe slash options were mostly a DEC thing that DOS and its
successors borrowed (I think they originated in TOPS-10). I don't
think there was any widespread syntax for options when the first
versions of Unix were written, and slash and dash options weren't the
only syntaxes used (e.g. JCL-ish key=value options were used on some
systems). The thing that I wonder about was why ">" wasn't used as the
directory separator when paths were added to Unix, since that's what
Multics used.

[TUHS] Dash options

[Ralph Corderoy]

Hi Andrew,

> The thing that I wonder about was why ">" wasn't used as the directory
> separator when paths were added to Unix, since that's what Multics
> used.

A slash has long been used to separate items in a hierarchy, e.g.
division, department, staff initials, or account, purchase-order number,
at least back to the early twentieth century.  So choosing it might have
seemed natural.
https://en.wikipedia.org/wiki/Slash_(punctuation)#Presenting_routes

And Multics had some kind of `attach' and `detach' of I/O streams, well
known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
with it meant `>' was earmarked early on.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] Dash options

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On 28 Nov 2017 11:18 +0000, from ralph at inputplus.co.uk (Ralph Corderoy):
> And Multics had some kind of `attach' and `detach' of I/O streams, well
> known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go
> with it meant `>' was earmarked early on.

Didn't early UNIX pipes use `<' to separate the commands involved?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Dash options

[Ralph Corderoy]

Hi Michael,

> Didn't early UNIX pipes use `<' to separate the commands involved?

No, you're thinking of `^'.

    $ /usr/heirloom/bin/sh
    $ date ^ wc
	  1       4      30
    $ ^D

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] Dash options

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

My theory was always that the Designers had the good sense to use ‘/‘ for a directory separator just because it was a lower case character and thus vastly easier to type than ‘>’.
-L

[TUHS] Dash options

[Paul Winalski]

On 11/28/17, Andrew Warkentin <andreww591 at gmail.com> wrote:
>
> Multics had dash options, so that's presumably where Unix got them
> from. I believe slash options were mostly a DEC thing that DOS and its
> successors borrowed (I think they originated in TOPS-10).

That's how I remember it.  I think slash was chosen because it looks
somewhat like a toggle switch.  MS/DOS patterned its command line
syntax after RT-11 and inherited the slash as a command option
introduction from there.  Unfortunately this meant that they couldn't
use slash as a directory separator when they got a hierarchical file
system, and so they chose backslash instead.  Nowadays the Windows
shell, and I think also the underlying image activation system
service, use an ugly algorithmic hack to support both directions of
slashes in file pathnames.

-Paul W.

[TUHS] Dash options

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> MS/DOS patterned its command line
> ​ ​
> syntax after RT-11 and inherited the slash as a command option
> introduction from there.

​Minor correction...   To do a CDC style patient zero history ;-) RT11 took
it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
PC-DOS ney MS/DOS took it from CP/M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/7dcb91e5/attachment-0001.html>

[TUHS] Dash options

[Greg 'groggy' Lehey]

On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
> Does anybody know the history of dash options?  Were they
> a UNIX thing or did UNIX borrow them from something earlier?

If you mean specificall the dash, I can't help much.  But there were
similar ideas elsewhere.  UNIVAC EXEC-8 (for the 1108, late 1960s) had
options that followed the command with a comma, like:

  @RUN,G GOPU,STANDARD,STANDARD
  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS
  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU
  @XQT PF.GOPU

The letters after the comma were option letters, conveniently packed
into a machine word so that they didn't require parsing.

OMEGA on the Univac 494 had something similar, but delimited by a
space rather than a comma, reminiscent of earlier tar syntax.

I don't know any other systems, but since UNIVAC and Unix aren't
closely related, I'd guess that there were similar ideas elsewhere
too.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/d846486a/attachment.sig>

[TUHS] Dash options

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

Greg 'groggy' Lehey <grog at lemis.com> wrote:
 |On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
 |> Does anybody know the history of dash options?  Were they
 |> a UNIX thing or did UNIX borrow them from something earlier?
 |
 |If you mean specificall the dash, I can't help much.  But there were
 |similar ideas elsewhere.  UNIVAC EXEC-8 (for the 1108, late 1960s) had
 |options that followed the command with a comma, like:
 |
 |  @RUN,G GOPU,STANDARD,STANDARD
 |  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS

"WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"

 |  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU

"PF IST PROGRAMM-DATEI MIT GOPU" or so.

 |  @XQT PF.GOPU
 |
 |The letters after the comma were option letters, conveniently packed
 |into a machine word so that they didn't require parsing.

Or.  Or the person who wrote the code above knew how German will
look like 50 years later.  Which could very well be, of course.
I am still impressed by the Lidlicker film the URL of which was
posted on this list, and the spirit and, well, let me say
progressiveness of the intellect of all the portrayed persons.
It was elevating to witness and also, a bit, become reminded of
this America in 2017.  A few weeks ago i could not do any
different but spent quite a few hours reading and thinking about,
and admiring Jacqueline Kennedy!  I was born almost a decade
later, but nonetheless seeing her sitting straight beside the
remains of her husband, i will never admire this woman enough.
And her naturalness.

--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)

[TUHS] Dash options

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

Hello.

 ||On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote:
 ||> Greg 'groggy' Lehey <grog at lemis.com> wrote:
 ||>> On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote:
 ||>>> Does anybody know the history of dash options?  Were they
 ||>>> a UNIX thing or did UNIX borrow them from something earlier?
 ||>>
 ||>> If you mean specificall the dash, I can't help much.  But there were
 ||>> similar ideas elsewhere.  UNIVAC EXEC-8 (for the 1108, late 1960s) had
 ||>> options that followed the command with a comma, like:
 ||>>
 ||>>  @RUN,G GOPU,STANDARD,STANDARD
 ||>>  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS
 ||>
 ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"
  ...
 ||>>  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU
 ||>
 ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so.
 ...

I have apologised for this brusque and rude tone in private.
Unfortunately Greg Lehey was the one who took up that thread.
Puh; he is also right correcting my statements, it should have
been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU"
instead of what i falsely claimed.

 |The question that should have been asked with mild interest and
 |very kind should have been "Why has German been used to comment
 |this code?" at first, i am afraid to realize.

--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)

[TUHS] Dash options

[Greg 'groggy' Lehey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On Tuesday,  5 December 2017 at 14:22:11 +0100, Steffen Nurpmeso wrote:
> Hello.
>
>>> On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote:
>>>> Greg 'groggy' Lehey <grog at lemis.com> wrote:
>  ||>>  @ADD,PL ASGDMS              . ASSIGNIERT DATENBASIS
>  ||>
>  ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS"
>   ...
>  ||>>  @ASG,A PF.                  . PF IST PROGRAMM-FILE MIT GOPU
>  ||>
>  ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so.
>  ...
>
> I have apologised for this brusque and rude tone in private.

Particularly in view of other posts on this list, I'd like to note
that I didn't take it to be rude.

> Unfortunately Greg Lehey was the one who took up that thread.
> Puh; he is also right correcting my statements, it should have
> been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU"
> instead of what i falsely claimed.
>
>> The question that should have been asked with mild interest and
>> very kind should have been "Why has German been used to comment
>> this code?" at first, i am afraid to realize.

This was a random choice of code that I happened to have on my
machine.  It was documentation for code written in Mannheim in
November 1973.  Arguably I should have removed the comments, but I
thought that the comment syntax was of marginal interest.

This has nothing more to do with Unix (it barely had in the first
place), so let's forget it.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171207/004e79b1/attachment.sig>