[Info-vax] Long uptime cut short by Hurricane Sandy

[Bill Gunshannon]

In article <e250e735-a95e-4304-bf93-5a33feb1bfe3 at l9g2000yqp.googlegroups.com>,
	AEF <spamsink2001 at yahoo.com> writes:
> On Feb 2, 11:03 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <1c8108f9-4792-4eed-8dec-501dd8649... at f6g2000yqm.googlegroups.com>,
>>         AEF <spamsink2... at yahoo.com> writes:
>>
>> > On Feb 2, 10:27 am, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
>> >> In article <nospam-DA6E3B.16021402022... at news.chingola.ch>,
>> >>         Paul Sture <nos... at sture.ch> writes:
>>
>> >> > In article
>> >> > <57c7dde5-875e-46e7-a4ff-095bc5d52... at w7g2000yqo.googlegroups.com>,
>> >> >  AEF <spamsink2... at yahoo.com> wrote:
>>
>> >> >> Well, let's see. What does # do in Unix? Why it's either tells you
>> >> >> what follows is a comment or when in a prompt what follows is a
>> >> >> command run with full super user powers!
>>
>> >> >> Comment vs super user. Nice.
>>
>> >> 1.  Prompt is the shell, not Unix.
>> > Extreme nitpick. It's a shell that runs in Unix, which makes it a Unix
>> > shell.
>>
>> It's also a shell that runs on VMS.  Does that make VMS Unix?
> 
> No, but the shell has its origins in Unix. (Well, I don't know all of
> computer history, but I've never seen "the shell" anywhere else.)

Well, I would guess that the term actually had its origins in Multics.
Remember the the ring (or shell) structure?  Priviliedged kernel in
the middle, user level at the outermost.

>                                                                   I
> can run other programs/shells/whatever in VMS and they can do various
> things. That's doesn't make VMS them, either. But that's beside the
> point.

So to you on Unix the CLI is the OS but on any other system that isn't
the case?

> 
> OK, it's a shell that is what is typically encountered running on Unix
> for command input. Is that explicit enough? Detailed enough? Specific
> enough?

And, except for the jargon, the exact same is true for every interactive
OS.  By the way, OS-9 also calls it a shell.  As does QNX (who are quite
adamant that QNX is not a version of Unix!!) In VMS jargon bash, csh, sh,
ksh, etc. are all CLI's.  And in Unix jargon DCL is a shell.

> 
> Shells like bash are a normal part of Unix. They're not a normal part
> of VMS.

See above.  It's jargon.  DCL is "a shell".  VMS people just choose
to use a different term to describe it.

> 
> On a Unix system you typically get a shell like bash, or ksh and the
> like. On VMS you typically get DCL. We have hundreds of servers at
> work and guess how many of them are running anything other than the
> Bourne shell or the bash shell? ZERO! We had as many as 40 or so VAX
> systems online at one point ca. 2001, and guess how many of them were
> running Bourne or bash? ZERO! Was our Stratus running bash or similar?
> NO! Do you see a pattern here? (^_^)

shell, CLI, they are exactly the same, functionally.  It's jargon, something
this industry is loaded with.  IBM mainframes don't run shells or DCL or a
CLI.  Well, actually the do, but they have their own name for it.  Jargon!!

> 
> Now, leaving the confines of my company:
> 
> So how many VMS systems are running bash, or any other "Unix" shell?

Who knows?  Who cares?

> If I logged into a VMS system and found myself with bash instead of
> DCL, I'd be very surprised! I suppose you wouldn't? 

Of course I would.  But there is a version of BASH for VMS so someone
thought it was worth the (non-trivial) effort.

>                                                      If I found VMS
> startup scripts written in bash, I'd be very surprised!

Yeah, and if I found Unix startup scripts written in DCL I wold be very
surprised.  What's the point?

> 
> If you're going to get this nitpicky, I can tear apart your democracy
> bit, too.
> 
> You obviously have no idea what democracy is. There is no country
> comprised of three wolves and a sheep. Wolves and sheep can't vote.
> They don't understand the concept. Wolves may well like to eat sheep,
> but that has nothing to do with democracy! 

Never heard the phrase "tyranny of the majority"?

>                                             Maybe you should stick with
> Unix.

Maybe you should study more history.

> 
>> >> 2.  Prompt is totally user settable and has no significance whatsoever.
>> > Really? Running su gives you a # prompt!!!
>>
>> Only if you su to root and root has the "#" set as his prompt.  If you
>> su to any other user you will get whatever they have as their prompt.
>>
>> >                                            I suppose su has nothing to
>> > do with Unix, either.
>>
>> Nobody said that.  But you obviously have no idea what su actually does.
> 
> It lets you become another user. I neglected to include the case in
> which you use it to become a user other than "root". I usually use
> sudo if I want to run a command as another user. But at times it's
> convenient to actually become root, or become the superuser (or
> whatever you want to call it), in which case by default I'm given the
> # in the prompt. 

OK, so it's the default.  At least for BASH.  So what?

>                   So normally I only use it to become root. Yep, my
> bad.

Still don't see the relevance of any of this.

> 
>>
>> >>   Here is mine on the University server:
>>
>> >>                   login as: bill
>> >>                   Using keyboard-interactive authentication.
>> >>                   Password:
>>
>> >>                   server1#
>> > Irrelevant.
>>
>> Why?  I am a regular user and my prompt is a "#".
> 
> Do I really have to explain this?
> 
> OK, I'll give it a shot:
> 
> Because you changed it! By default you don't get the # unless you
> become the superuser. The default behavior is as I described. When you
> run the su command to become root, the prompt is changed to #. And why
> is this? To remind you that you are root, the superuser, that a simple
> type or other error can cause grave harm to your system! 

OK, if that's what you think the reason is, your welcome to your
opinion.  But I think most Unix sysadmins know who they are logged
in as without something as volatile as the prompt to remind them.

>                                                          I don't know
> why YOU use #. That's irrelevant. We're talking about Unix, or "the
> shell", or su -- not Bill's Unix session.

And you are obsessing over something that is volatile and trivial to
change and therefore of no real value.

> 
>> >> 3.  I'll bet you also think the su command means "super user".
>> > You bet wrong. Also irrelevant.
>>
>> So, what do you think the su command really does?
> 
> It lets you become, or "switch" to another user. I normally only use
> it to become root, hence my previous post(s). And when you do so, it
> gives you the # prompt. 

Assuming it has not been changed.

>                          And what is the purpose of the # prompt? To
> warn you that your in superuser mode, or root, or whatever nitpicky
> term you want to use.

OK, you can go on believing that.  It's as good a reason as any.

> 
>>
>> >> > You missed out shebang, as in:
>>
>> >> > #!/bin/sh
>> > Oh, so # in a shell script is Unix, but in a prompt from the su
>> > command it's "the shell".
>>
>> Huh?  What are you talking about.  In one case it's output and in the
>> other it's input.  And in both cases it is shell.
> 
> Ah, so all of a sudden, su, which is not a built-in command (correct
> me if I'm wrong -- as if I have to say it!), is now part of the shell.

No, but it spawns a new shelli with a different euid.  Period.  Nothing else.
The prompts comes from the shell.  That is output.  if you type a "#" or
run a script with "#" in it that is input.  Why is that concept so hard
to grasp?

> Isn't that like saying SET PROCESS/PRIV=ALL is a built-in DCL
> command?

Don't know.  Don't know what "SET PROCESS/PRIV=ALL" means or what is
and is not builtin to DCL.  And I know enough not to make claims about
things I don't know or understand.

> 
> OK, so here we have a character, the # character, that is used by the
> same thing (as you said immediately above), to be either the comment
> character or the root prompt. This entity, "the shell", as you put it
> just above, and this use of #, is normally part of a Unix session.

There you go again.  It has nothing to do with Unix.  The VMS version
of BASH will exhibit the same behavior.  As to the CLI's in QNX and OS-9.
It has to do with the shell.  Period.  Which can be running on any
number of different OSes.

> Yes, you can change it, but so what? The default is what I described.
> I can paint the green leaves of a plant red. So what? The leaves of a
> plant are normally green. Or, if you nitpick that, I can swap one kind
> of plant in my garden with another.

Another irrelevant comment that basicly makes no sense in this context.

> 
> So how many VMS systems are running bash, 

Don't know and don't care.  But I would be willing to bet the number is
greater than 0.

>                                            or any other shell that
> typically runs on a Unix system? How many IBM systems are running
> this? How many Stratus (VOS) systems? 

Don't know and don't care.

>                                        How many Windows systems? 

Lots of them unless you figure the Cygwin guys did al lthat work
for no particular reason.

>                                                                  Now,
> how many Unix systems are running DCL, JCL, VOS, etc.?

Probably very close to 0.  Is there something relevant to that fact?

> 
> So I think we're agreed at least that the same entity, "the shell",
> uses # in two extremely "opposite" ways. What we disagree on is
> whether this entity has anything to do with Unix. I've never
> encountered it anywhere else. 

Bash on VMS, bash on Windows, OS-9 (in all it's versions), QNX.
And then we have anything running a version of POSIX that includes
a POSIX Shell.  Oh, and if we go back in time to the days when the
Software Tools Virtual Operating System was still in vogue, it had
a shell that exhibited the same behavior regarding the use of the
"#" and ran on over 40 systems and 100 OSes.  Your experience is
hardly the standard.

>                                 I think it's use anywhere else is
> minimal at best. I don't believe these shells were originally written
> for other OSes. AFAIK, they originate in the Unix world. 

See above.  While the term "shell" may have originated in Unix
(but I still think it probably originated in Multics) the use of a
Unix style shell as a CLI was much more widespread than you seem
willing to accept.  Not being a fan of POSIX, I don't know how
many POSIX compliant system today have "shells".  Oh, wait, as for
VMS, I forgot about EUNICE.  Bourne and C-shells both available.
Where is Wollongong when we really need them.  :-)

>                                                           It is a
> normal part of the Unix world. It is at least prevalent, if not
> ubiquitous, in the Unix world, and not anywhere else.

Really???

> 
> Let me review:
> 
> Look,
> 
> You go into the VMS world and you get a $ prompt. You can change that
> to something else. So what? By default, VMS gives you a $. And the
> comment character is by default a "!". And these are DCL things. You
> can change the prompt, but so what? It's normally $.

Well, your the one making a big thing about the importance of the
prompt.  I have said all along that it is much to volatile to have
any real significance.

> 
> You go into the Unix world and you get the # as I described. Yes, you
> can change that, but as given to you, the Unix world uses # for at
> least three different purposes. Please don't re-iterate nonsense about
> it's a shell and what not. You start out using Unix and you get
> characters whose default behavior can be either the start of totally
> harmless comment or a command with superuser powers that can decimate
> the machine. 

Re-read what you just said.  An "#" does not start "a command with superuser
powers".  It is a prompt displayed on the screen in that context.
And you haven't even touched on the shells that don't work like that
at all.  I have used an "MSDOS shell" that mimicked the functionality
of COMMAND.COM.  There actually was a commercial product tha did DCL
on Unix systems.  And then there was the shell I wrote that mimiced
the menu system from UCSD-Pascal.

>               Yeah, there's the shebang, too. Makes things even worse!
> Oh, and now you'll tell me I can rewrite the kernel, too.

The "shebang" has nothing to do with the kernel.  It's a function of....
wait for it....
The Shell.

> 
> OK, maybe I should have used the term "vanilla". Vanilla shell or
> vanilla Unix or vanilla kernel or whatever you're going to tell me it
> is. When a user starts out using Unix systems using the typical shells
> they come with, the # can render the text following it either as
> comments or as potentially very destructive commands.

And here you are confusiong output and input again.  And, there is
no guarantee that the sysadmin won't have already changed the default
prompt before a user even logs on the first time.  That's why the 
prompts are insignificant and one should never rely on that to
determine what user they are running something as.

> 
> So, in other words: In such a world, the # character can be either the
> comment character or a prompt (or part of a prompt) whose intended
> purpose is to remind you that you now have full-blown, root, superuser
> powers. And I think it's a bad design to have a the same character
> used for extreme opposite purposes.

OK, but people who actually use Unix all the time don't have that problem.
And, as I have already said, the use of the "#" as a prompt is volatile
and trivial to change.  I have seen a nymber of systems where the prompt
contains the username.  That would solve your problem and make sure
you knew when you were in a shell with root priviledges.

That's one of the strengths of Unix, infinitely (well almost) custom-
izable and fairly easy at that.

> 
>>
>> >                             I don't believe su is a built-in. Hey,
>> > correct me if I'm wrong on that.
>>
>> Who ever said it was?  And what does that have to do with the prompt
>> output by the shell?
> 
> You did up above. You say (or clearly imply) that su, which when used
> to become root, puts a # in your prompt, is part of the shell!

No I did not.  su spawns a new shell with the euid of the user who's
login is provided as a parameter.  su doesn't have a prompt.  Well,
except for asking for a password.

> 
>> >> >http://en.wikipedia.org/wiki/Shebang_%28Unix%29
>>
>> >> I was going to mention that as the on place where a line beginning with
>> >> an octothorpe is not a comment and is not ignored.
>>
>> >> bill
>>
>> > I vote for matzo ball soup. And then some roast chicken (with
>> > paprika), potatoes, and some beets.
>>
>> And that statement makes as much sense as anything you have said about
>> Unix. You really should stick to VMS.
> 
> It makes more sense than wolves and sheep voting in a democracy, much
> less being an electorate.
> 

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>