Re: [TUHS] Cryptic Unix Commands

Re: [TUHS] Cryptic Unix Commands

[Noel Chiappa]

    > From: Norman Wilson

    > It is just plain wrong to code
    >  kill(9, pid)

_All_ uses of magic numbers in numeric form are wrong!

	Noel

Re: [TUHS] Cryptic Unix Commands

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Wed, Sep 5, 2018 at 11:44 AM, Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Norman Wilson
>
>     > It is just plain wrong to code
>     >  kill(9, pid)
>
> _All_ uses of magic numbers in numeric form are wrong!
>
>         Noel
>

I completely agree, although you can do worse. A junior programmer I worked
with at MIT wrote (in IBM assembler)

twelv dc 10

(I probably have the syntax wrong, but he was declaring the value of
symbolic name 'twelv' to be 10). I have no idea why he did this. He didn't
last long.

[-- Attachment #2: Type: text/html, Size: 1305 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Kurt H Maier]

On Wed, Sep 05, 2018 at 11:44:35AM -0400, Noel Chiappa wrote:
>     > From: Norman Wilson
> 
>     > It is just plain wrong to code
>     >  kill(9, pid)
> 
> _All_ uses of magic numbers in numeric form are wrong!
> 
> 	Noel

https://www.boost.org/doc/libs/1_68_0/boost/utility/binary.hpp


khm

Re: [TUHS] Cryptic Unix Commands

[Norman Wilson]

Ron Natalie:

  I use the numbers but I think it stems from the days when kill didn't take
  the names.    It's easier for me to remember -1 and -9 than to remember what
  the mnemonics are.

====

Me too.  And not just the kill command; the (real) shell's
trap command too.

It's all just muscle memory, not a desire to save keystrokes.

On the rare occasions when I need to send a post-modern signal
like SIGSTOP or SIGCONT, I use the name.

As an aside, why do modern kill and sh accept only the
abbreviated form of the signal name, not the full name;
e.g. kill -STOP is OK, kill -SIGSTOP an error?  When we
taught kill about that sometime in (I think) the 9th Edition
era at Research, we allowed either form.  I think it was
Doug who insisted on it, and he was right.

All this applies to shell commands, not to programs.
It is just plain wrong to code
	kill(9, pid)
in C.

Norman Wilson
Toronto ON

Re: [TUHS] Cryptic Unix Commands

[Chet Ramey]

On 9/5/18 11:04 AM, Norman Wilson wrote:

> As an aside, why do modern kill and sh accept only the
> abbreviated form of the signal name, not the full name;
> e.g. kill -STOP is OK, kill -SIGSTOP an error?  

It's the standard:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html#tag_20_64

"Historical versions of kill have not written the SIG prefix for the -l
option and have not recognized the SIG prefix on signal_names."

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28

"Implementations may also accept the names with the SIG prefix; no known
historical shell does so."

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito <web@loomcom.com> wrote:

> ...
> I've begun to wonder whether 3B2 hardware was used very much inside of
> Bell Labs.
>
I'd be curious to hear of people that actually used it.  AT&T forced you to
buy one with SVR3 as the porting base (I'd have never had bought the one we
had a Stellar otherwise).
The only time I ever knew anyone run one, was to check to see the behavior
of some code/validation testing of RFS *etc*...

The HW as pretty slow/inflexible compared to 68020/68030 which came out
around the same time, so it was just not interesting - *i.e.* 'JAWS' - Just
another work station' and it did not have a display.  IIRC, it was a server
and pretty inflexible in the I/O subsystem for that use.
Sun would quickly produce the first Sparcs, which as Larry has pointed out,
kicked butt
and were cheaper
.   The MIPS chip would emerge
with lots of designs,
and for that matter the 040 and the 386 would appear soon their after
, too.

I've always felt that the 3Bx series was an example of fighting the
previous war; other than 3B4000 (which had high reliability but other
issues in practice to use it), there was never anything that made them
special - compared to everyone else.

The only 'successful' product
that I
can
remember that used the WE32100
was the
second version (*a.k.a.* product version) of the Blit (Bart's first version
was 68000 IIRC).  Does anyone know of another product?  I think I was told
the 5ESS
changed
 the SLICs
design
from the original 68000 design to WE32100 but I was no
longer associated with anyone working on it by then, so I don't know.

Dennis once remarked to a couple of us that the WE32100 was an example of
AT&T wanting to make sure it had its own recipe to make processors, but it
was not clear it was worth it.   BTW: around the same time both AT&T and HP
were making their own DRAM too.  It was common thinking in management at
tech companies - telling folks that they needed to be 'vertically
integrated.'  But in the case of both HP and AT&T there internally produced
DRAM chips cost 2-3 times what the merchant market cost; so besides the
investment in the fab (which was huge) it was a pretty expensive insurance
policy.

That said, this was also the end times for the idea of the 'second
source.'   Chip manufacturers would be required to license their designs to
some one else (for instance AMD was originally Intel's second source).   I
think HP was using a second source license for their memory, but IIRC AT&T
had developed its own because they had higher reliability standards.

[-- Attachment #2: Type: text/html, Size: 6115 bytes --]

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Mary Ann Horton]

[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]

Inside AT&T (but outside research) there was considerable pressure to 
use AT&T products (3B, System V, BLIT/5620, Datakit) rather than the 
externally developing Sun/Ethernet/TCP suite, especially in the mid-late 
1980s.  We all (mostly) hated them and wanted Suns, but we were told 
"eat your own dog food." The 3B20 and 3B5 were awful, but the 3B2 had 
potential.  Once we got a working TCP/IP network in Bell Labs the tide 
turned in favor of Suns.


On 08/24/2018 09:06 AM, Clem Cole wrote:
> On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito <web@loomcom.com 
> <mailto:web@loomcom.com>> wrote:
>
>     ...
>     I've begun to wonder whether 3B2 hardware was used very much
>     inside of Bell Labs.
>
> I'd be curious to hear of people that actually used it.  AT&T forced 
> you to buy one with SVR3 as the porting base (I'd have never had 
> bought the one we had a Stellar otherwise).
> The only time I ever knew anyone run one, was to check to see the 
> behavior of some code/validation testing of RFS /etc/...
>
> The HW as pretty slow/inflexible compared to 68020/68030 which came 
> out around the same time, so it was just not interesting - /i.e./ 
> 'JAWS' - Just another work station' and it did not have a display.  
> IIRC, it was a server and pretty inflexible in the I/O subsystem for 
> that use.
> Sun would quickly produce the first Sparcs, which as Larry has pointed 
> out, kicked butt
> and were cheaper
> .   The MIPS chip would emerge
> with lots of designs,
> and for that matter the 040 and the 386 would appear soon their after
> , too.
>
> I've always felt that the 3Bx series was an example of fighting the 
> previous war; other than 3B4000 (which had high reliability but other 
> issues in practice to use it), there was never anything that made them 
> special - compared to everyone else.
>
> The only 'successful' product
> that I
> can
> rememberthat used the WE32100
> was the
> second version (/a.k.a./product version) of the Blit (Bart's first 
> version was 68000 IIRC).  Does anyone know of another product?  I 
> think I was told the 5ESS
> changed
>  the SLICs
> design
> from the original 68000 design to WE32100 but I was no
> longer associated with anyone working on it by then, so I don't know.
>
> Dennis once remarked to a couple of us that the WE32100 was an example 
> of AT&T wanting to make sure it had its own recipe to make processors, 
> but it was not clear it was worth it.   BTW: around the same time both 
> AT&T and HP were making their own DRAM too.  It was common thinking in 
> management at tech companies - telling folks that they needed to be 
> 'vertically integrated.'  But in the case of both HP and AT&T there 
> internally produced DRAM chips cost 2-3 times what the merchant market 
> cost; so besides the investment in the fab (which was huge) it was a 
> pretty expensive insurance policy.
>
> That said, this was also the end times for the idea of the 'second 
> source.'   Chip manufacturers would be required to license their 
> designs to some one else (for instance AMD was originally Intel's 
> second source).   I think HP was using a second source license for 
> their memory, but IIRC AT&T had developed its own because they had 
> higher reliability standards.


[-- Attachment #2: Type: text/html, Size: 9318 bytes --]

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

below...

On Mon, Aug 27, 2018 at 12:04 PM Mary Ann Horton <mah@mhorton.net> wrote:

> Inside AT&T (but outside research) there was considerable pressure to use
> AT&T products (3B, System V, BLIT/5620, Datakit) rather than the externally
> developing Sun/Ethernet/TCP suite, especially in the mid-late 1980s.  We
> all (mostly) hated them and wanted Suns, but we were told "eat your own dog
> food."
>
That was always my impression.     IIRC Mt. Xinu made a poster (and Kolstad
made a series of buttons) stating "4.2 > V"  I remember somebody (ber
probably) had it hanging in Whippany and certain supervisors were not
amsussed.

The 3B20 and 3B5 were awful, but the 3B2 had potential.
>
It was not so much they we awful IMO, is that they were nothing special -
too little too late.   The 3B20 (the only computer I even knew with a 'pull
starter'), was basically a 1MIP 780 and took the same resources (machine
room, multiple 19" cabinets, etc); when a 68020 based Masscomp, Apollo or
Sun was at 4-5 MIPS and fit under your desk.   As I said, fighting the last
war.

The 3B2 got the size and performance more inline, but the SW was still
behind and by them it was arguable if a BLIT over a serial line could
compete with the builtin graphics.   For the former, did the 3B2 only run
SRV3 and SRV4?   The others ran SVR0-2 which was not even close to BSD.  By
SVR3 the OS finally got better.    BILT had some great stuff, but I think
the shear volume of programmers using X-Windows, particularly once it ran
on super cheap HW (*i.e.* Wintel based) it was tough.



> Once we got a working TCP/IP network in Bell Labs the tide turned in favor
> of Suns
>
Although by the time of its release, the default system for

SRV4 was Wintel.

Clem

[-- Attachment #2: Type: text/html, Size: 3696 bytes --]

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On Mon, 27 Aug 2018, Clem Cole wrote:

> That was always my impression.     IIRC Mt. Xinu made a poster (and 
> Kolstad made a series of buttons) stating "4.2 > V"  I remember somebody 
> (ber probably) had it hanging in Whippany and certain supervisors were 
> not amsussed.

I remember seeing a photo of that button.  Somewhere (I think) I have a 
PS/PDF (or was it a sticker?) of "Intel outside" which I stuck to my 
SparcStation.

Unfortunately the latter part of my career was having to support SysVile 
and pretending that I liked it...

-- Dave

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Larry McVoy]

On Tue, Aug 28, 2018 at 10:24:12AM +1000, Dave Horsfall wrote:
> Unfortunately the latter part of my career was having to support SysVile and
> pretending that I liked it...

I don't think anyone really liked it.  Maybe Roger Faulkner.  And there
are the Joyent crew.  Even they, when I told them I had tried it and
wasn't impressed, asked if I had /opt/GNU/bin in my path first?  Huh?
Decades have gone by, Sun is gone, and they are still cleaning to the
compatibilty argument for /usr/bin?  SunOS was the system that everyone
used because they wanted to, Solaris was what people used because they
had to.

Re: [TUHS] Research UNIX on the AT&T 3B2?

[arnold]

Larry McVoy <lm@mcvoy.com> wrote:

> Decades have gone by, Sun is gone, and they are still cleaning [sic] to the
> compatibilty argument for /usr/bin?

As hard as it is to believe in this day and age, there are still plenty
of places where that compatibility is what sells systems.

> SunOS was the system that everyone used because they wanted to, Solaris
> was what people used because they had to.

Nicely put!

Arnold

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Dave Horsfall]

On Tue, 28 Aug 2018, arnold@skeeve.com wrote:

> Larry McVoy <lm@mcvoy.com> wrote:

[...]

>> SunOS was the system that everyone used because they wanted to, Solaris 
>> was what people used because they had to.
>
> Nicely put!

Signature material, in fact!  I loved SunOS 4.1.4, and had to eat a shit 
sandwich when they went to Solaris (but continue to run BSD-like systems 
at home; first BSDi, then FreeBSD; the MacBook is at least vaguely 
BSD-ish, and the only reason that I also have Debian is to see what the 
penguins have broken this time).

-- Dave

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Harald Arnesen]

Dave Horsfall [2018-08-29 00:33]:

> Signature material, in fact!  I loved SunOS 4.1.4, and had to eat a shit 
> sandwich when they went to Solaris (but continue to run BSD-like systems 
> at home; first BSDi, then FreeBSD; the MacBook is at least vaguely 
> BSD-ish, and the only reason that I also have Debian is to see what the 
> penguins have broken this time).

So you don't think MacOS has broken more than the penguins have?
-- 
Hilsen Harald

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Dave Horsfall]

On Wed, 29 Aug 2018, Harald Arnesen wrote:

>> Signature material, in fact!  I loved SunOS 4.1.4, and had to eat a 
>> shit sandwich when they went to Solaris (but continue to run BSD-like 
>> systems at home; first BSDi, then FreeBSD; the MacBook is at least 
>> vaguely BSD-ish, and the only reason that I also have Debian is to see 
>> what the penguins have broken this time).
>
> So you don't think MacOS has broken more than the penguins have?

Stuff I write on FreeBSD pretty much works on my Mac (the latter has mo 
serial ports, and thus uses a dodgy USB/serial cable with an equally-dodgy 
driver that hangs the system to the point of requiring a *power cycle*).

And vice-versa; I had to learn how to control DTR etc on a genuine
serial port on the FreeBSD box (I am writing a user-level driver for
a serial device).

As for Penguin/OS (and trying to figure out just which header file uses 
which flags, when I'm using low-level Perl I/O), then forget it.

What really blew my gasket is that "stty -f" on *BSD is "stty -F" on 
Penguin/OS, despite them copying every other flag.

I had a look at how they (Linux) wrote stty.c, and nearly threw up.

So, yes, that's pretty much my answer...

-- Dave

Re: [TUHS] Research UNIX on the AT&T 3B2?

[Theodore Y. Ts'o]

On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote:
> 
> What really blew my gasket is that "stty -f" on *BSD is "stty -F" on
> Penguin/OS, despite them copying every other flag.

I'm pretty sure the addition of "stty -f" and "stty -F" is a fairly
late innovation.  i.e., it wasn't there when Linux "copied" stty's
user interface.

In BSD 4.3 and early Linux (which is when I still was maintaining
Linux's serial driver) you always had to do:

	stty dec < /dev/ttyS0

Really, why did those young whippersnappers had to add an option, when
redirection worked perfectly well and required one less character to
type?  :-)

					- Ted

Re: [TUHS] Cryptic Unix Commands

[Warren Toomey]

On Tue, Aug 28, 2018 at 11:23:10PM -0400, Theodore Y. Ts'o wrote:
> 	stty dec < /dev/ttyS0
> 
> Really, why did those young whippersnappers had to add an option, when
> redirection worked perfectly well and required one less character to
> type?  :-)

This reminded me of other semi-cryptic commands. I remember mistyping
"kill -1 1" as "kill -9 1" with the inevitable consequences.

	Warren

Re: [TUHS] Cryptic Unix Commands

[Jeremy C. Reed]

On Wed, 29 Aug 2018, Warren Toomey wrote:

> This reminded me of other semi-cryptic commands. I remember mistyping
> "kill -1 1" as "kill -9 1" with the inevitable consequences.

Last week I typed "crontab -" (missed the "e" for -e)  and then without 
realizing what happened Ctrl-C didn't work, typed Ctrl-D.  Argh. Lost 
around 20 crontabs which were in a directory I didn't backup. Luckily I 
had a syslog file with my recent jobs to recreate it, but lost all my 
comments and commented-out entries (for over ten years).

Re: [TUHS] Cryptic Unix Commands

[Dave Horsfall]

On Wed, 29 Aug 2018, Warren Toomey wrote:

> This reminded me of other semi-cryptic commands. I remember mistyping 
> "kill -1 1" as "kill -9 1" with the inevitable consequences.

Hands up all those who have *not* done that...

-- Dave

Re: [TUHS] Cryptic Unix Commands

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

On 08/29/2018 04:03 PM, Dave Horsfall wrote:
> Hands up all those who have *not* done that...

My faux pas is usually meaning to type "telinit q" but reaching a bit 
too far and accidnetally typing "telinit 1".

*facepalm*

/me starts the (not so) slow walk of shame to the DC.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] Cryptic Unix Commands

[William Pechter]

Did that one at Johnson and Johnson Health Care Systems around '95 as an IBM Global Services guy.  Ran to the computer room to restart services and Oracle on AIX.

Apologized to the customer.  IBM demanded a formal Root Cause Analysis for the fat finger with recommendations for avoiding the problem in the future.
I proposed redesigned ascii keyboards where Q and 1 weren't adjacent.

Management suits not amused.  Customer took it as simple accident and dealt with the 5-10 minute outage.

Bill

-----Original Message-----
From: Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
To: tuhs@minnie.tuhs.org
Sent: Wed, 29 Aug 2018 18:09
Subject: Re: [TUHS] Cryptic Unix Commands

On 08/29/2018 04:03 PM, Dave Horsfall wrote:
> Hands up all those who have *not* done that...

My faux pas is usually meaning to type "telinit q" but reaching a bit 
too far and accidnetally typing "telinit 1".

*facepalm*

/me starts the (not so) slow walk of shame to the DC.



-- 
Grant. . . .
unix || die

Re: [TUHS] Cryptic Unix Commands

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On 08/29/2018 04:21 PM, William Pechter wrote:
> Did that one at Johnson and Johnson Health Care Systems around '95 as an 
> IBM Global Services guy.  Ran to the computer room to restart services 
> and Oracle on AIX.

@^*% happens.

Anybody that tells you it doesn't happen to them is lying.

> Apologized to the customer.  IBM demanded a formal Root Cause Analysis 
> for the fat finger with recommendations for avoiding the problem in 
> the future.  I proposed redesigned ascii keyboards where Q and 1 weren't 
> adjacent.

I remember things like that.

I always liked to admit things like that to the customer.  I felt that 
it fostered trust.  More than once I went to a customer that trusted me 
and told them that something was not me and they took me at my word, 
primarily because of that established trust.

> Management suits not amused.  Customer took it as simple accident and 
> dealt with the 5-10 minute outage.

Nice.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Larry McVoy]

On Wed, Aug 29, 2018 at 05:04:48PM -0600, Grant Taylor via TUHS wrote:
> On 08/29/2018 04:21 PM, William Pechter wrote:
> >Apologized to the customer.  IBM demanded a formal Root Cause Analysis for
> >the fat finger with recommendations for avoiding the problem in the
> >future.  I proposed redesigned ascii keyboards where Q and 1 weren't
> >adjacent.
> 
> I remember things like that.
> 
> I always liked to admit things like that to the customer.  I felt that it
> fostered trust.  More than once I went to a customer that trusted me and
> told them that something was not me and they took me at my word, primarily
> because of that established trust.

Yep, I'm the same way and I think most good to stellar engineers are the
same way.  How can you fix your stuff if you are in denial about it being
broken.

And I agree with you Grant, on the trust building.  Customers love it 
when you are honest.

Re: [TUHS] Cryptic Unix Commands

[William Pechter]

[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]

The only time I hid something like that was back in my Field Service days.

I smoked a third party data comm board which cost $$$$ while trying to
replace it.
DEC had me do something for one of my customers on a third party hardware
install.   I had no docs, training or experience with the board.
Unfortunately, the vendor didn't key a power cable and I flipped the damned
two pin wire blowing the chip top right off the board.

Wasn't sure it was my fault.  I stayed with the call until they got another
board and they got the box up and running and I finally figured I was the
cause
of the issue.  Didn't volunteer the info since I wasn't sure.   Probably
should've taken the hit.  When I did the bad thing I took the hit.

One of these was shorting +15v (IIRC) to Init L on the Unibus on an
11/780.  Blew the bits off all the boards back to the Unibus termination on
the DW780
and out to the M9302 Unibus terminator.

Spent the next two days rebuilding the box.
I still had a great relationship with the customer for the next 4 years at
the site.

People understand mistakes and will forgive.  Lying to a customer to keep
up a corporate image will never be forgotten if you get caught.

I remember stealing HDA's off of brand new RA81's at DEC's Princeton HQ to
get them out to customer sites before failures in the field from the glue
liquification issue.
Customers will stand by a company that puts them first and delivers serious
effort.
Nowadays the outsourced techs are pretty much parts carriers and swappers
with no ability to push company deliveries up and often they act as a
delaying action until the
company can deliver the correct services.

Bill


--
  d|i|g|i|t|a|l had it THEN.  Don't you wish you could still buy it now!
 pechter-at-gmail.com


On Wed, Aug 29, 2018 at 7:05 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 08/29/2018 04:21 PM, William Pechter wrote:
> > Did that one at Johnson and Johnson Health Care Systems around '95 as an
> > IBM Global Services guy.  Ran to the computer room to restart services
> > and Oracle on AIX.
>
> @^*% happens.
>
> Anybody that tells you it doesn't happen to them is lying.
>
> > Apologized to the customer.  IBM demanded a formal Root Cause Analysis
> > for the fat finger with recommendations for avoiding the problem in
> > the future.  I proposed redesigned ascii keyboards where Q and 1 weren't
> > adjacent.
>
> I remember things like that.
>
> I always liked to admit things like that to the customer.  I felt that
> it fostered trust.  More than once I went to a customer that trusted me
> and told them that something was not me and they took me at my word,
> primarily because of that established trust.
>
> > Management suits not amused.  Customer took it as simple accident and
> > dealt with the 5-10 minute outage.
>
> Nice.
>
>
>
> --
> Grant. . . .
> unix || die
>
>

[-- Attachment #2: Type: text/html, Size: 3760 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Dan Mick]

On 08/29/2018 03:03 PM, Dave Horsfall wrote:
> On Wed, 29 Aug 2018, Warren Toomey wrote:
> 
>> This reminded me of other semi-cryptic commands. I remember mistyping
>> "kill -1 1" as "kill -9 1" with the inevitable consequences.
> 
> Hands up all those who have *not* done that...
> 
> -- Dave

<raises hand>

I always type signal names.  Life's too short to worry about saving
three characters.

Re: [TUHS] Cryptic Unix Commands

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On 08/29/2018 04:31 PM, Dan Mick wrote:
> I always type signal names.  Life's too short to worry about saving 
> three characters.

Signal names?  I've always used numbers / quit.  I don't think I've ever 
seen anybody do otherwise.

/me goes to read the man page.

Thank you for the pro tip Dan.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Dave Horsfall]

On Wed, 29 Aug 2018, Grant Taylor via TUHS wrote:

> Signal names?  I've always used numbers / quit.  I don't think I've ever 
> seen anybody do otherwise.

I've never used signal names (other than SIGTERM, when it got changed from 
14 to 15 for no good reason that I could see; at least it's now the 
default signal).

-- Dave

Re: [TUHS] Cryptic Unix Commands

[ron]

I use the numbers but I think it stems from the days when kill didn't take
the names.    It's easier for me to remember -1 and -9 than to remember what
the mnemonics are.


> -----Original Message-----
> From: TUHS <tuhs-bounces@minnie.tuhs.org> On Behalf Of Dave Horsfall
> Sent: Wednesday, August 29, 2018 6:04 PM
> To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
> Subject: Re: [TUHS] Cryptic Unix Commands
> 
> On Wed, 29 Aug 2018, Warren Toomey wrote:
> 
> > This reminded me of other semi-cryptic commands. I remember mistyping
> > "kill -1 1" as "kill -9 1" with the inevitable consequences.
> 
> Hands up all those who have *not* done that...
> 
> -- Dave

Re: [TUHS] Cryptic Unix Commands

[John P. Linderman]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

I remember doing a fresh install of unix on a VAX with another sysadmin. We
had spent a couple hours getting everything ready to go, and he had created
a bunch of temporary directories under /tmp to hold intermediate work. All
started with ".", so, in /tmp, he entered "rm -r .*". Unfortunately, that
matched .. as well. We knew something had gone very wrong when we got a
"/bin/rm: text busy" message as rm tried to remove itself.

On Thu, Aug 30, 2018 at 7:06 AM, <ron@ronnatalie.com> wrote:

> I use the numbers but I think it stems from the days when kill didn't take
> the names.    It's easier for me to remember -1 and -9 than to remember
> what
> the mnemonics are.
>
>
> > -----Original Message-----
> > From: TUHS <tuhs-bounces@minnie.tuhs.org> On Behalf Of Dave Horsfall
> > Sent: Wednesday, August 29, 2018 6:04 PM
> > To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
> > Subject: Re: [TUHS] Cryptic Unix Commands
> >
> > On Wed, 29 Aug 2018, Warren Toomey wrote:
> >
> > > This reminded me of other semi-cryptic commands. I remember mistyping
> > > "kill -1 1" as "kill -9 1" with the inevitable consequences.
> >
> > Hands up all those who have *not* done that...
> >
> > -- Dave
>
>

[-- Attachment #2: Type: text/html, Size: 1939 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Thu, Aug 30, 2018 at 7:07 AM <ron@ronnatalie.com> wrote:

> I use the numbers but I think it stems from the days when kill didn't take
> the names.    It's easier for me to remember -1 and -9 than to remember
> what
> the mnemonics are.
>
Same here - there first time I saw the mnemonics were in the built-in kill
command in csh.    Which was usefule for "kill -cont"

but to this day, since like Ron I grew on fifth/sixth/seventh edition which
used numbers, the ones that I remember and care about are screwed into my
fingers.

I never have an issue with -1 vs -9 with kill, but I do not have great
story about how as a young engineer I wiped out the life's work of visiting
professor because Tektronix had the 0 and 1 keys next to each other on one
of the terminals they made.  It was the console of our 11/60 and we had two
RK05's and I fat fingured /dev/r...0 instead of 1.  Bad stuff.

Clem

[-- Attachment #2: Type: text/html, Size: 1889 bytes --]

Re: [TUHS] Cryptic Unix Commands

[William Pechter]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

At least in the old days drives had Write Protect switches.
Screw IBM for the in cable drive select lines on diskette and leaving off Write Protect on hard disks.  Some disks had write protect jumpers on the boards... They should have been The STANDARD.

Bill

⁣Sent from BlueMail ​

On Aug 30, 2018, 09:25, at 09:25, Clem Cole <clemc@ccc.com> wrote:
>On Thu, Aug 30, 2018 at 7:07 AM <ron@ronnatalie.com> wrote:
>
>> I use the numbers but I think it stems from the days when kill didn't
>take
>> the names.    It's easier for me to remember -1 and -9 than to
>remember
>> what
>> the mnemonics are.
>>
>Same here - there first time I saw the mnemonics were in the built-in
>kill
>command in csh.    Which was usefule for "kill -cont"
>
>but to this day, since like Ron I grew on fifth/sixth/seventh edition
>which
>used numbers, the ones that I remember and care about are screwed into
>my
>fingers.
>
>I never have an issue with -1 vs -9 with kill, but I do not have great
>story about how as a young engineer I wiped out the life's work of
>visiting
>professor because Tektronix had the 0 and 1 keys next to each other on
>one
>of the terminals they made.  It was the console of our 11/60 and we had
>two
>RK05's and I fat fingured /dev/r...0 instead of 1.  Bad stuff.
>
>Clem

[-- Attachment #2: Type: text/html, Size: 2999 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Thu, Aug 30, 2018 at 10:31 AM William Pechter <pechter@gmail.com> wrote:

> At least in the old days drives had Write Protect switches.
>
Not the issue - both disks were RW.  I was running as root and ran a
program that lacked a check it shoud have had it (because I was lazy and
never put it in there).



> Screw IBM for the in cable drive select lines on diskette
>
You of course realized that was because of field service issues of course.
 Setting all floppies (and later ST-506 disks) on the PC and using a twist
in the cable meant they did not have to ask FS folks to set the jumpers
properly.




> and leaving off Write Protect on hard disks.  Some disks had write protect
> jumpers on the boards...
>
Hmmm.. I thought all disks at least had a strap.   WD, CDC, Seagate,
Shuggart, Toshiba all supported the strap.  The IBM disks I remember did
not also, but I'll take your word for it, it would have been like them to
have removed it to save the connector cost.




> They should have been The STANDARD.
>
Hmmm.. I'm not at home, but I think I have both the ST-412/506 and ESDI
specs in a filing cab somewhere.  I thought the standard did defined it.
(Intel blocks 'bitsavers.org' for some reason so I can not look online but
I think  http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf is
likely to have it in there).

Clem

>

[-- Attachment #2: Type: text/html, Size: 3380 bytes --]

Re: [TUHS] Cryptic Unix Commands

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Thu, Aug 30, 2018 at 9:03 AM Clem Cole <clemc@ccc.com> wrote:

> On Thu, Aug 30, 2018 at 10:31 AM William Pechter <pechter@gmail.com>
> wrote:
>
>> Screw IBM for the in cable drive select lines on diskette
>>
> You of course realized that was because of field service issues of
> course.   Setting all floppies (and later ST-506 disks) on the PC and using
> a twist in the cable meant they did not have to ask FS folks to set the
> jumpers properly.
>

 Ah yes, the original zeroconfig :)

Warner

[-- Attachment #2: Type: text/html, Size: 1153 bytes --]

Re: [TUHS] Cryptic Unix Commands

[William Pechter]

Early plug and play.

Would have worked better if they trained the PC techs in how the stuff worked.

Bill
Old ex-tech turned sysadmin


-----Original Message-----
From: Warner Losh <imp@bsdimp.com>
To: Clem Cole <clemc@ccc.com>
Cc: William Pechter <pechter@gmail.com>, The Eunuchs Hysterical Society <tuhs@tuhs.org>
Sent: Thu, 30 Aug 2018 11:22
Subject: Re: [TUHS] Cryptic Unix Commands

On Thu, Aug 30, 2018 at 9:03 AM Clem Cole <clemc@ccc.com> wrote:

> On Thu, Aug 30, 2018 at 10:31 AM William Pechter <pechter@gmail.com>
> wrote:
>
>> Screw IBM for the in cable drive select lines on diskette
>>
> You of course realized that was because of field service issues of
> course.   Setting all floppies (and later ST-506 disks) on the PC and using
> a twist in the cable meant they did not have to ask FS folks to set the
> jumpers properly.
>

 Ah yes, the original zeroconfig :)

Warner