f



Unix without shell



Another thread (on find ... -exec ...) got me thinking about "pure
Unix", i.e. Unix without a shell.  I realize that, with the exception
of the occasional find ... -exec ..., and maybe at login time, I
don't know of any other instance in which I interact with Unix
without some shell's intervention.  In fact I don't have a very
clear idea of where the shell ends and Unix begins.  I want to
remedy this situation.

I'm sure it's a royal pain to deal with Unix without the services
of a shell, but I would like to experience it first hand.  Is it
possible?  I suppose I could create some do-nothing program, and
set it up as my shell.  Is there a simpler way?

Also, does anyone know of a reference book that describes the pure
Unix user interface, without any reference to a shell?

Thanks!

	-bill
0
bill
5/27/2004 3:04:17 PM
comp.unix.shell 15484 articles. 2 followers. Post Follow

37 Replies
815 Views

Similar Articles

[PageSpeed] 1

On Thu, 27 May 2004 15:04:17 +0000 (UTC), bill 
  <please_post@nomail.edu> wrote:

> I'm sure it's a royal pain to deal with Unix without the services
> of a shell, but I would like to experience it first hand.  Is it
> possible?  I suppose I could create some do-nothing program, and
> set it up as my shell.  Is there a simpler way?
>
> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?
>
The shell is the user interface.


-- 
May 25 	International Towel Day, in honour of Douglas N. Adams

0
Bill
5/27/2004 3:13:33 PM
bill <please_post@nomail.edu> writes:

> Another thread (on find ... -exec ...) got me thinking about "pure
> Unix", i.e. Unix without a shell.  I realize that, with the
> exception of the occasional find ... -exec ..., and maybe at login
> time, I don't know of any other instance in which I interact with
> Unix without some shell's intervention.  In fact I don't have a very
> clear idea of where the shell ends and Unix begins.  I want to
> remedy this situation.
> 
> I'm sure it's a royal pain to deal with Unix without the services
> of a shell, but I would like to experience it first hand.  Is it
> possible?

Sure, that's what shells do. Just be a shell :-)

> I suppose I could create some do-nothing program, and
> set it up as my shell.  Is there a simpler way?

I think, by "experience it first hand" you mean you want to make
system and library calls yourself. If so, just write a program that
does that. Shells are just programs, after all (it's only software).

> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?

The man pages come to mind. Also

http://www.opengroup.org/onlinepubs/009695399/functions/contents.html

which should more or less describe systems which are more or less
POSIX compliant.

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.
0
joe
5/27/2004 3:49:21 PM
In <t5dho1-tuk.ln1@don.localnet> Bill Marcum <bmarcum@iglou.com.urgent> writes:

>On Thu, 27 May 2004 15:04:17 +0000 (UTC), bill 
>  <please_post@nomail.edu> wrote:

>> I'm sure it's a royal pain to deal with Unix without the services
>> of a shell, but I would like to experience it first hand.  Is it
>> possible?  I suppose I could create some do-nothing program, and
>> set it up as my shell.  Is there a simpler way?
>>
>> Also, does anyone know of a reference book that describes the pure
>> Unix user interface, without any reference to a shell?
>>
>The shell is the user interface.

Are you saying that if one deleted all the shell executables on
the disk and rebooted the system there would be no way for a user
to interact with it at the console (i.e. no user interface)?

	-bill
 
>May 25 	International Towel Day, in honour of Douglas N. Adams

0
bill
5/27/2004 3:51:57 PM
joe@invalid.address writes:

> bill <please_post@nomail.edu> writes:
> 
> > Another thread (on find ... -exec ...) got me thinking about "pure
> > Unix", i.e. Unix without a shell.  I realize that, with the
> > exception of the occasional find ... -exec ..., and maybe at login
> > time, I don't know of any other instance in which I interact with
> > Unix without some shell's intervention.  In fact I don't have a very
> > clear idea of where the shell ends and Unix begins.  I want to
> > remedy this situation.
> > 
> > I'm sure it's a royal pain to deal with Unix without the services
> > of a shell, but I would like to experience it first hand.  Is it
> > possible?
> 
> Sure, that's what shells do. Just be a shell :-)

Sorry, I was feeling a bit whimsical for a minute there.

The first personal computers had toggle switches on the front panel,
with no keyboard, disk drives etc. In order to do anything you had to
load instructions into the computer a byte at a time by using the
toggle switches. That's experiencing it first hand, and people wound
up building operating systems and shells as fast as they could, so
they didn't have to do that any more.

I suspect you could probably still find machines like that around, but
I don't think you'd get much enjoyment out of them. At least, for me,
emacs and a compiler are as close as I care to get to experiencing it
first hand. I spend the rest of my designing solutions for problems my
boss gives me.

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.
0
joe
5/27/2004 4:02:30 PM
In article <c9501h$mm1$1@reader2.panix.com>,
 bill <please_post@nomail.edu> wrote:

> Another thread (on find ... -exec ...) got me thinking about "pure
> Unix", i.e. Unix without a shell.  I realize that, with the exception
> of the occasional find ... -exec ..., and maybe at login time, I
> don't know of any other instance in which I interact with Unix
> without some shell's intervention.  In fact I don't have a very
> clear idea of where the shell ends and Unix begins.  I want to
> remedy this situation.
> 
> I'm sure it's a royal pain to deal with Unix without the services
> of a shell, but I would like to experience it first hand.  Is it
> possible?  I suppose I could create some do-nothing program, and
> set it up as my shell.  Is there a simpler way?
> 
> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?

If you use a system with a GUI interface, and never bring up a terminal 
window, you can experience Unix without an interactive shell.  A good 
example of this is a Macintosh running Mac OS X -- most non-power users 
probably can go months without using the Terminal application.

You can't realistically delete the shell programs from the system, 
though.  Some of the programs that are run in the background by the 
system are shell scripts, and they'll fail if there's no shell.  And 
many programs that you execute manually are also shell scripts (for 
instance, if you download software it usually comes with scripts to 
configure and install it).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
5/27/2004 4:04:57 PM
In <m3smdlyi21.fsf@invalid.address> joe@invalid.address writes:

>joe@invalid.address writes:

>> bill <please_post@nomail.edu> writes:
>> 
>> > Another thread (on find ... -exec ...) got me thinking about "pure
>> > Unix", i.e. Unix without a shell.  I realize that, with the
>> > exception of the occasional find ... -exec ..., and maybe at login
>> > time, I don't know of any other instance in which I interact with
>> > Unix without some shell's intervention.  In fact I don't have a very
>> > clear idea of where the shell ends and Unix begins.  I want to
>> > remedy this situation.
>> > 
>> > I'm sure it's a royal pain to deal with Unix without the services
>> > of a shell, but I would like to experience it first hand.  Is it
>> > possible?
>> 
>> Sure, that's what shells do. Just be a shell :-)

>Sorry, I was feeling a bit whimsical for a minute there.

>The first personal computers had toggle switches on the front panel,
>with no keyboard, disk drives etc. In order to do anything you had to
>load instructions into the computer a byte at a time by using the
>toggle switches.

OK, how about this.  Unix was released on 1971 and the Bourne shell
was released on 1975.  What did Unix users use between 1971 and
1975? Did they use a now-defunct shell, or did they interact with
the system some other way?

	-bill

0
bill
5/27/2004 4:05:59 PM
Barry Margolin <barmar@alum.mit.edu> writes:

> In article <c9501h$mm1$1@reader2.panix.com>,
>  bill <please_post@nomail.edu> wrote:
> 
> > Another thread (on find ... -exec ...) got me thinking about "pure
> > Unix", i.e. Unix without a shell.  I realize that, with the exception
> > of the occasional find ... -exec ..., and maybe at login time, I
> > don't know of any other instance in which I interact with Unix
> > without some shell's intervention.  In fact I don't have a very
> > clear idea of where the shell ends and Unix begins.  I want to
> > remedy this situation.
> > 
> > I'm sure it's a royal pain to deal with Unix without the services
> > of a shell, but I would like to experience it first hand.  Is it
> > possible?  I suppose I could create some do-nothing program, and
> > set it up as my shell.  Is there a simpler way?
> > 
> > Also, does anyone know of a reference book that describes the pure
> > Unix user interface, without any reference to a shell?
> 
> If you use a system with a GUI interface, and never bring up a
> terminal window, you can experience Unix without an interactive
> shell.  A good example of this is a Macintosh running Mac OS X --
> most non-power users probably can go months without using the
> Terminal application.

I'd argue that the GUI is a shell, just not a command line
interpreter.

Maybe that's not a useful distinction but it seems like a good one to
me. 

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.
0
joe
5/27/2004 4:25:21 PM
In article <m3isehygzz.fsf@invalid.address>, joe@invalid.address wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
> > If you use a system with a GUI interface, and never bring up a
> > terminal window, you can experience Unix without an interactive
> > shell.  A good example of this is a Macintosh running Mac OS X --
> > most non-power users probably can go months without using the
> > Terminal application.
> 
> I'd argue that the GUI is a shell, just not a command line
> interpreter.
> 
> Maybe that's not a useful distinction but it seems like a good one to
> me. 

If you're going to go there, I'll argue that the toggle switches on 
early computers were a shell, just that it was implemented in hardware 
rather than software. :)

So I guess the way to answer the OP's question is what another poster 
said: put an application program in the login shell field of your passwd 
entry (or just have your .profile end with "exec application").  If the 
application doesn't provide any form of shell escape, you're limited to 
what it can do, and can't execute arbitrary programs (which I'd say is 
the basic functionality of a shell).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
5/27/2004 4:38:41 PM
"bill" <please_post@nomail.edu> wrote in message news:c952qt$ni9$1@reader2.panix.com...
: In <t5dho1-tuk.ln1@don.localnet> Bill Marcum <bmarcum@iglou.com.urgent> writes:
:
: >On Thu, 27 May 2004 15:04:17 +0000 (UTC), bill
: >  <please_post@nomail.edu> wrote:
:
: >> I'm sure it's a royal pain to deal with Unix without the services
: >> of a shell, but I would like to experience it first hand.  Is it
: >> possible?  I suppose I could create some do-nothing program, and
: >> set it up as my shell.  Is there a simpler way?
: >>
: >> Also, does anyone know of a reference book that describes the pure
: >> Unix user interface, without any reference to a shell?
: >>
: >The shell is the user interface.
:
: Are you saying that if one deleted all the shell executables on
: the disk and rebooted the system there would be no way for a user
: to interact with it at the console (i.e. no user interface)?

Your system wouldn't even properly reboot.  Most of the services are
started by shell scripts.  You can't even start X - all X environments
I know require scripts to login.

Dan Mercer

:
: -bill
:
: >May 25 International Towel Day, in honour of Douglas N. Adams
:


0
Dan
5/27/2004 4:56:26 PM
Barry Margolin <barmar@alum.mit.edu> writes:

> In article <m3isehygzz.fsf@invalid.address>, joe@invalid.address wrote:
> 
> > Barry Margolin <barmar@alum.mit.edu> writes:
> > > If you use a system with a GUI interface, and never bring up a
> > > terminal window, you can experience Unix without an interactive
> > > shell.  A good example of this is a Macintosh running Mac OS X --
> > > most non-power users probably can go months without using the
> > > Terminal application.
> > 
> > I'd argue that the GUI is a shell, just not a command line
> > interpreter.
> > 
> > Maybe that's not a useful distinction but it seems like a good one
> > to me.
> 
> If you're going to go there, I'll argue that the toggle switches on
> early computers were a shell, just that it was implemented in
> hardware rather than software. :)

Fair enough.

> So I guess the way to answer the OP's question is what another
> poster said: put an application program in the login shell field of
> your passwd entry (or just have your .profile end with "exec
> application").  If the application doesn't provide any form of shell
> escape, you're limited to what it can do, and can't execute
> arbitrary programs (which I'd say is the basic functionality of a
> shell).

That's still not going to let him experience unix "directly", however
I'm still a little unsure about what he meant by that. 

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.
0
joe
5/27/2004 4:56:57 PM
"bill" <please_post@nomail.edu> wrote in message news:c9501h$mm1$1@reader2.panix.com...
:
:
:
: Another thread (on find ... -exec ...) got me thinking about "pure
: Unix", i.e. Unix without a shell.  I realize that, with the exception
: of the occasional find ... -exec ..., and maybe at login time, I
: don't know of any other instance in which I interact with Unix
: without some shell's intervention.  In fact I don't have a very
: clear idea of where the shell ends and Unix begins.  I want to
: remedy this situation.
:
: I'm sure it's a royal pain to deal with Unix without the services
: of a shell, but I would like to experience it first hand.  Is it
: possible?  I suppose I could create some do-nothing program, and
: set it up as my shell.  Is there a simpler way?
:
: Also, does anyone know of a reference book that describes the pure
: Unix user interface, without any reference to a shell?
:
: Thanks!
:
: -bill

The very definition of a Unix system (based on the peanut M&M theory)
is a root kernel,  surrounded by chocolatey user space,  with a thin candy shell.


MMMM!  Chocolate  Argh

Dan Mercer


0
Dan
5/27/2004 4:58:49 PM
2004-05-27, 16:05(+00), bill:
[...]
> OK, how about this.  Unix was released on 1971 and the Bourne shell
> was released on 1975.  What did Unix users use between 1971 and
> 1975? Did they use a now-defunct shell, or did they interact with
> the system some other way?

They used Thompson's shell.
http://minnie.tuhs.org/UnixTree/V4/usr/man/man1/sh.1.html

-- 
Stephane
0
Stephane
5/27/2004 5:19:07 PM
bill <please_post@nomail.edu> wrote:
> 
> 
> 
> Another thread (on find ... -exec ...) got me thinking about "pure
> Unix", i.e. Unix without a shell.  I realize that, with the exception
> of the occasional find ... -exec ..., and maybe at login time, I
> don't know of any other instance in which I interact with Unix
> without some shell's intervention.  In fact I don't have a very
> clear idea of where the shell ends and Unix begins.  I want to
> remedy this situation.
> 
> I'm sure it's a royal pain to deal with Unix without the services
> of a shell, but I would like to experience it first hand.  Is it
> possible?  I suppose I could create some do-nothing program, and
> set it up as my shell.  Is there a simpler way?
> 
> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?

Use GUI like XDM, GDM, KDM.  And, never open up 'xterm' and likes. :-)
You can't really delete all shells from your system, since some commands
are really shell script.

-- 
William Park, Open Geometry Consulting, <opengeometry@yahoo.ca>
Linux solution/training/migration, Thin-client
0
William
5/27/2004 5:30:35 PM
2004-05-27, 16:56(+00), Dan Mercer:
[...]
> Your system wouldn't even properly reboot.  Most of the services are
> started by shell scripts.  You can't even start X - all X environments
> I know require scripts to login.

Not to speak of the standard C library relying on a "sh" shell
for its system(3) or popen(3) functions.

But, there's no problem building a system with a UNIX kernel and
not any single shell (for instance for embedded systems). But,
maybe you wouldn't call it a UNIX system then.

-- 
Stephane
0
Stephane
5/27/2004 6:10:21 PM
joe@invalid.address wrote:
 > bill <please_post@nomail.edu> writes:
 >>I suppose I could create some do-nothing program, and
 >>set it up as my shell.  Is there a simpler way?
 >
 > I think, by "experience it first hand" you mean you want to make
 > system and library calls yourself. If so, just write a program that
 > does that. Shells are just programs, after all (it's only software).

I don't think he's asking for something that extreme; I think what he
means is the ability to run executables, but with no shell features or
the syntax that supports them:

parameter substitution: $ ${...}
special variables (e.g. PATH)
file name patterns: * ? [...]
redirection: > < >> <<
pipes: |
grouping: {} () ;
conditional: && ||
control structure: if then else fi case esac for while do done
etc.

-- 
Kevin Rodgers

0
Kevin
5/27/2004 6:59:46 PM
Kevin Rodgers <ihs_4664@yahoo.com> writes:

> joe@invalid.address wrote:
>  > bill <please_post@nomail.edu> writes:
>  >>I suppose I could create some do-nothing program, and
>  >>set it up as my shell.  Is there a simpler way?
>  >
>  > I think, by "experience it first hand" you mean you want to make
>  > system and library calls yourself. If so, just write a program that
>  > does that. Shells are just programs, after all (it's only software).
> 
> I don't think he's asking for something that extreme; I think what he
> means is the ability to run executables, but with no shell features or
> the syntax that supports them:

What does that mean? I'm having a hard time thinking of how that can
be achieved without some kind of shell or writing a program that gets
loaded apart from a shell somehow.

If what you're suggesting is "some program which reads input from
the user and executes programs", isn't that a shell?

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.
0
joe
5/27/2004 7:39:00 PM

In infinite wisdom bill answered:
> In <t5dho1-tuk.ln1@don.localnet> Bill Marcum <bmarcum@iglou.com.urgent> writes:
> 
> 
>>On Thu, 27 May 2004 15:04:17 +0000 (UTC), bill 
>> <please_post@nomail.edu> wrote:
> 
> 
>>>I'm sure it's a royal pain to deal with Unix without the services
>>>of a shell, but I would like to experience it first hand.  Is it
>>>possible?  I suppose I could create some do-nothing program, and
>>>set it up as my shell.  Is there a simpler way?
>>>
>>>Also, does anyone know of a reference book that describes the pure
>>>Unix user interface, without any reference to a shell?
>>>
>>
>>The shell is the user interface.
> 
> 
> Are you saying that if one deleted all the shell executables on
> the disk and rebooted the system there would be no way for a user
> to interact with it at the console (i.e. no user interface)?

This is more or less true. I imagine you could interface with a
windowing system, if one would run without a shell to set up
it's enviornment. But I've not worked with a windowing system
that will start without a login shell.

And without bourne shell, unix won't even boot. The rc scripts are
bourne shell.

Rich

> 	-bill
>  
> 
>>May 25 	International Towel Day, in honour of Douglas N. Adams
> 
> 

0
Rich
5/27/2004 8:00:15 PM
In <m3ekp5yfja.fsf@invalid.address> joe@invalid.address writes:

>That's still not going to let him experience unix "directly", however
>I'm still a little unsure about what he meant by that. 

I was thrown off by the statement I've seen many times: "find's
exec does not use a shell".  From this I made the unfounded
extrapolation that it was possible for a user to interact with Unix
from the console without going through a shell.

After reading the posts on this thread, I have a much better
understanding of this whole business of "find's exec not using a
shell."  find's exec doesn't *use* a shell because it *is* a (very
limited and awkward) shell:

  $ find -exec date \; -prune
  Thu May 27 17:52:39 EDT 2004



	-bill

0
bill
5/27/2004 10:09:49 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.unix.shell bill <please_post@nomail.edu> suggested:

[..]

> I'm sure it's a royal pain to deal with Unix without the services
> of a shell, but I would like to experience it first hand.  Is it
> possible?  I suppose I could create some do-nothing program, and
> set it up as my shell.  Is there a simpler way?

Not at all, the system won't be able to startup without a shell,
as others mentioned already.

> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?

The shell is the *nix user interface, there are some Linux distro
and probably mac OS-X where you could get around using a shell,
if you really want.

But then, the various shells on *nix are their biggest advantage
against other OS. The flexibility can't be made up by any GUI,
which adds tremendous power to the shell, since you can have
multiple xterm on a single virtual desktop.
;)

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAtmf3AkPEju3Se5QRAleOAKCV1gy+tu8uVY5FDjMOdq6Pra3fYgCgsf9o
Oqn3gK1juao+2rA8380LcM8=
=oR8z
-----END PGP SIGNATURE-----
0
Michael
5/27/2004 10:13:12 PM
BUT, If I remember the boot sequence right, you COULD have a program 
that is started via the inittab, and all other programs turned off, 
including ttys and then not running any of the rcs, there for no telnet, 
rsh, ssh etc.

So the kernel would boot, it would exec init, init runs this fictional 
binary.  You could actually try this using runlevel 4, which is usually 
unused.

What would it be good for? Well this fictional program could turn the 
box into some kind of appliance, say a router, or even create a CLI with 
some other metafor. Of course you would still need a shell to set it all 
up.

for that matter you could have the kernel start a program other than 
init. It's often suggested as a failure procedure (forget the root 
password?) to use a kernel parameter of init=/usr/bin/sh. There is no 
reason why you can't have something else in there.

AND it would indeed still be unix, it just would not have the standard 
interface (not that they're all tha standard anymore, zsh anyone?)

That all said... the shell is the unix experience to a large part.  It 
is how all the standard services get started, as you know by now, and 
the best method for (power) user interaction.  It really is just a CLI 
and all OSs have them, tho some are better than others. The windows cli 
(command.exe, cmd.com) still leaves a lot to be desired, that's why many 
of us install cygwin.

Indeed I've often thought about writing a CLI to emulate the one from 
the system that I cut my teeth on: Data General's AOS/VS.

bk


William Park wrote:
> bill <please_post@nomail.edu> wrote:
> 
>>
>>
>>Another thread (on find ... -exec ...) got me thinking about "pure
>>Unix", i.e. Unix without a shell.  I realize that, with the exception
>>of the occasional find ... -exec ..., and maybe at login time, I
>>don't know of any other instance in which I interact with Unix
>>without some shell's intervention.  In fact I don't have a very
>>clear idea of where the shell ends and Unix begins.  I want to
>>remedy this situation.
>>
>>I'm sure it's a royal pain to deal with Unix without the services
>>of a shell, but I would like to experience it first hand.  Is it
>>possible?  I suppose I could create some do-nothing program, and
>>set it up as my shell.  Is there a simpler way?
>>
>>Also, does anyone know of a reference book that describes the pure
>>Unix user interface, without any reference to a shell?
> 
> 
> Use GUI like XDM, GDM, KDM.  And, never open up 'xterm' and likes. :-)
> You can't really delete all shells from your system, since some commands
> are really shell script.
> 

0
Bob
5/27/2004 11:50:27 PM
bill <please_post@nomail.edu> writes:

> After reading the posts on this thread, I have a much better
> understanding of this whole business of "find's exec not using a
> shell."  find's exec doesn't *use* a shell because it *is* a (very
> limited and awkward) shell:
>
>   $ find -exec date \; -prune
>   Thu May 27 17:52:39 EDT 2004

What it comes down to is how a process executes another process.
First you should know that Unix has the model of fork() and exec().
        Step 1 - Process exeuctes fork() system call.

At this point, there are two identical copies of the process, with the
exception being the return value of the fork() command. The one that
returns non-zero is the parent, so it continues.

The one that fork() returns a value of zero knows it's a child. It
generally executes another process (step 2). Remember, the calling
process can be find(1) sh(1), etc.  If the process knows the name, and
location (path) of the new process, as well as the arguments to the
new process, it can execute it directly, without starting up a shell.

But if the arguments contain shell meta-characters, like * ? $ [] {} `
etc. etc.  The calling process cannot, or rather, does not want to
process them, it's much easier to call up a shell and have the shell
process those characters.

So the calling process either execs a process directly, or it executes
a shell which executes the process.

The decision is simply - do you want to process all of those meta-characters yourself?
Or perhaps ignore the meta-characters?
Or do you want to have the shell handle the meta-characters for you?

I can conceive of a shell that does not process the * meta-character, so you can type
        rename *.txt *.old

But then the rename process has to handle the "*" as well as all of
the other processes the shell calls has to handle "*"  as well.


Personally, I like the shell processing the meta-characters.  This
means I can write a script in just a few characters, and my script doesn't
need to handle all of the meta-character expansion.


By the way, the earlier Unix shell didn't handle the "*" meta-character (globbing).
If you typed

        script *.txt
then the script would see "*.txt" as the argument. If you wanted it to expand to match 
all filenames that ended in ".txt" you had to call the "glob" program, i.e.

        script `glob *.txt`

But the early Unix users decided that globbing was so useful, the
shell should to it for you. So the function of glob was moved into the shell.


So if you want a "pure" Unix experience, you might be able to find a
shell that doesn't do globbing. You can (I can't quite believe I am
saying this) use the csh/tcsh and disable globbing.


-- 
Sending unsolicited commercial e-mail to this account incurs a fee of 
$500 per message, and acknowledges the legality of this contract.
0
Bruce
5/28/2004 12:51:49 AM
Quoth bill <please_post@nomail.edu>:
> Another thread (on find ... -exec ...) got me thinking about "pure
> Unix", i.e. Unix without a shell.  I realize that, with the
> exception of the occasional find ... -exec ..., and maybe at login
> time, I don't know of any other instance in which I interact with
> Unix without some shell's intervention.  In fact I don't have a very
> clear idea of where the shell ends and Unix begins.  I want to
> remedy this situation.
>
> I'm sure it's a royal pain to deal with Unix without the services of
> a shell, but I would like to experience it first hand.  Is it
> possible?  I suppose I could create some do-nothing program, and set
> it up as my shell.  Is there a simpler way?
>
> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?

You mean, as in "my applications are running straight out of init.d"?

The usual case where this is used is in embedded applications, where
you don't particularly want a shell at all, but rather have a few apps
that take over the system.

If you want to do more 'general purpose' stuff, then you need to run
something like a shell.  

Or perhaps a Lisp system; one of the classic jokes is that of running
Emacs as the "operating system," and running it, instead of a shell,
would be a good example of this...
-- 
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/
Rules of  the Evil  Overlord #28. "My  pet monster  will be kept  in a
secure cage  from which it  cannot escape and  into which I  could not
accidentally stumble." <http://www.eviloverlord.com/>
0
Christopher
5/28/2004 2:42:11 AM
In article <c9501h$mm1$1@reader2.panix.com>, bill <please_post@nomail.edu> writes:
> 
> 
> 
> Another thread (on find ... -exec ...) got me thinking about "pure
> Unix", i.e. Unix without a shell.  I realize that, with the exception
> of the occasional find ... -exec ..., and maybe at login time, I
> don't know of any other instance in which I interact with Unix
> without some shell's intervention.  In fact I don't have a very
> clear idea of where the shell ends and Unix begins.  I want to
> remedy this situation.
> 
> I'm sure it's a royal pain to deal with Unix without the services
> of a shell, but I would like to experience it first hand.  Is it
> possible?  I suppose I could create some do-nothing program, and
> set it up as my shell.  Is there a simpler way?
> 
> Also, does anyone know of a reference book that describes the pure
> Unix user interface, without any reference to a shell?
> 
> Thanks!
> 
> 	-bill

Traditional, Unix has the shell as a user interface.
Also Unix has an API for binary programs.

Maybe you think of Windows; it first came with command.com,
with file manager, and with program manager.
Today both and more are integrated into the Explorer, so you
hardly need the command line (now named cmd.exe).

If you have such an Explorer in Unix, it will do everything
through the API, and you will hardly need a shell.
(The system() call as part of the API spawns a shell, but this
happens invisible.)

Because the graphics are not part of the kernel, graphics can
crash without crashing the kernel, but in this case you would
need the shell for a "soft" recovery.

You should look for a Gnome book or a KDE book; these two
desktops have something that is close to the Explorer.

-- 
Michael Tosch
IT Specialist
HP Managed Services Germany
Phone +49 2407 575 313
Mail: michael.tosch:hp.com


0
eedmit
5/28/2004 9:26:57 AM
Christopher Browne <cbbrowne@acm.org> writes:

> Or perhaps a Lisp system; one of the classic jokes is that of running
> Emacs as the "operating system," and running it, instead of a shell,
> would be a good example of this...

It's no joke.
When I first started work at my company (1988) several of the people
were using Symbolics workstations. The entire system is based on Lisp.

The concept of data and code being separate became blurred.
Code modified and generated new code all the time.


-- 
Sending unsolicited commercial e-mail to this account incurs a fee of 
$500 per message, and acknowledges the legality of this contract.
0
Bruce
5/28/2004 10:51:43 AM
Stephane CHAZELAS wrote:

> [roff source]
> http://minnie.tuhs.org/UnixTree/V4/usr/man/man1/sh.1.html

(and http://www.in-ulm.de/~mascheck/bourne/index.html#origins
 for htmlized versions of sh(1) roff sources from that time)
0
Sven
5/28/2004 11:53:01 AM
Barry Margolin wrote:

> [...] a Macintosh running Mac OS X -- most non-power users 
> probably can go months without using the Terminal application.

<URL:http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/background/chapter_2_section_4.html>    ;-)

"A Mac OS X user should never have to resort to the command line to
 perform any task in an application with a graphical user interface.
 This is especially important to remember since the BSD user environment
 may not even be installed on a users system. The libraries and kernel
 environment are of course there by default, but the tools may not be."
0
Sven
5/28/2004 11:56:25 AM
In <2hnn83Ff7mt5U3@uni-berlin.de> Christopher Browne <cbbrowne@acm.org> writes:
>Or perhaps a Lisp system; one of the classic jokes is that of running
>Emacs as the "operating system," and running it, instead of a shell,
>would be a good example of this...

Come to think of it, maybe I already do this.  I work on a byzantine
setup (little choice on the matter; it's all imposed by the company):
Win2K workstation from which I connect to a Unix machine using
PuTTY and Hummingbird Exceed as my X-server.  I used to get a
terminal when I connected via PuTTY, and once I logged in I'd invoke
Emacs, which usually would be up for days or weeks on end.
Occasionally, some problem with the terminal or the shell from
which Emacs was originally invoked would require closing it, taking
along a perfectly prime-of-life-healthy Emacs session to the grave.
So I set up an Emacs-dedicated PuTTY connection in which I give,
as argument to the ssh login command, the command to invoke Emacs.
Now the death of my terminal window does not affect my Emacs and
vice versa, although I find that its harder to rattle Emacs than
it is to rattle my terminal window.

(I'm sure there are far simpler ways of solving my original problem,
but I have an uncanny talent for complicating things.)

In fact, lately I've gotten into the habit of using the Emacs shell,
instead of the terminal window, so I'm working on Emacs 90% of the
time.  It has all the benefits of screen, plus, after 15 years of
Emacs use, I find it more intuitive.

	-bill
0
bill
5/28/2004 12:18:21 PM

In infinite wisdom Sven Mascheck answered:
> Barry Margolin wrote:
> 
> 
>>[...] a Macintosh running Mac OS X -- most non-power users 
>>probably can go months without using the Terminal application.
> 
> 
> <URL:http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/background/chapter_2_section_4.html>    ;-)
> 
> "A Mac OS X user should never have to resort to the command line to
>  perform any task in an application with a graphical user interface.
>  This is especially important to remember since the BSD user environment
>  may not even be installed on a users system. The libraries and kernel
>  environment are of course there by default, but the tools may not be."

I was under the impression that the new MAC OS, based upon MACH, would
have to include a shell.

This may be slightly OT, but I don't like the way windows is going at
all, Microsoft seems to think it owns all your data, and I was
considering either going to Linux or the Apple. But Apple looked
viable only if it included a shell. Does the new MacOS include any
shells? And if so, which ones? Anybody know?

TIA.

Rich



0
Rich
5/28/2004 1:59:57 PM
In article <40B745DD.80009@somewhere.com>, Rich <someone@somewhere.com> 
wrote:

> In infinite wisdom Sven Mascheck answered:
> > Barry Margolin wrote:
> > 
> > 
> >>[...] a Macintosh running Mac OS X -- most non-power users 
> >>probably can go months without using the Terminal application.
> > 
> > 
> > <URL:http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix
> > /background/chapter_2_section_4.html>    ;-)
> > 
> > "A Mac OS X user should never have to resort to the command line to
> >  perform any task in an application with a graphical user interface.
> >  This is especially important to remember since the BSD user environment
> >  may not even be installed on a users system. The libraries and kernel
> >  environment are of course there by default, but the tools may not be."
> 
> I was under the impression that the new MAC OS, based upon MACH, would
> have to include a shell.
> 
> This may be slightly OT, but I don't like the way windows is going at
> all, Microsoft seems to think it owns all your data, and I was
> considering either going to Linux or the Apple. But Apple looked
> viable only if it included a shell. Does the new MacOS include any
> shells? And if so, which ones? Anybody know?

Yes, MacOS includes bash, tcsh, and zsh (but not ksh).  Bash is 
necessary for the system to run -- like most Unix systems, many system 
processes are shell scripts.

I think the paragraph that was quoted above was Apple's original ideal 
for OS X, but they didn't make it all the way.  You can even find places 
in their user documentation where the recommended action is to execute a 
command in the Terminal.  For instance, their Network Utility provides a 
GUI interface to tools like ping and traceroute, but the documentation 
tells you to use the "man" command in a Terminal window to learn how to 
interpret the output or use the underlying command directly (so you can 
use options).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
5/28/2004 3:41:31 PM
joe@invalid.address wrote:
 > Kevin Rodgers <ihs_4664@yahoo.com> writes:
 >>I don't think he's asking for something that extreme; I think what he
 >>means is the ability to run executables, but with no shell features or
 >>the syntax that supports them:
 >
 > What does that mean? I'm having a hard time thinking of how that can
 > be achieved without some kind of shell or writing a program that gets
 > loaded apart from a shell somehow.
 >
 > If what you're suggesting is "some program which reads input from
 > the user and executes programs", isn't that a shell?

Well, it's a command line interface.  But without file name patterns,
variable and command substitution, pipes and redirection, functions and
alises, etc. I wouldn't call it a shell.

-- 
Kevin Rodgers

0
Kevin
5/28/2004 5:17:53 PM
Kevin Rodgers <ihs_4664@yahoo.com> writes:

> joe@invalid.address wrote:
>  > Kevin Rodgers <ihs_4664@yahoo.com> writes:
>  >>I don't think he's asking for something that extreme; I think
>  >>what he means is the ability to run executables, but with no
>  >>shell features or the syntax that supports them:
>  >
>  > What does that mean? I'm having a hard time thinking of how that
>  > can be achieved without some kind of shell or writing a program
>  > that gets loaded apart from a shell somehow.
>  >
>  > If what you're suggesting is "some program which reads input from
>  > the user and executes programs", isn't that a shell?
> 
> Well, it's a command line interface.  But without file name
> patterns, variable and command substitution, pipes and redirection,
> functions and alises, etc. I wouldn't call it a shell.

What would you call a shell? If it acts as an intermediary between the
user and the OS, isn't that a shell?

Joe
-- 
"Surprise me"
  - Yogi Berra when asked where he wanted to be buried.
0
joe
5/28/2004 6:09:35 PM

In infinite wisdom Barry Margolin answered:
> In article <40B745DD.80009@somewhere.com>, Rich <someone@somewhere.com> 
> wrote:
> 
> 
>>In infinite wisdom Sven Mascheck answered:
>>
>>>Barry Margolin wrote:
>>>
>>>
>>>
>>>>[...] a Macintosh running Mac OS X -- most non-power users 
>>>>probably can go months without using the Terminal application.
>>>
>>>
>>><URL:http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix
>>>/background/chapter_2_section_4.html>    ;-)
>>>
>>>"A Mac OS X user should never have to resort to the command line to
>>> perform any task in an application with a graphical user interface.
>>> This is especially important to remember since the BSD user environment
>>> may not even be installed on a users system. The libraries and kernel
>>> environment are of course there by default, but the tools may not be."
>>
>>I was under the impression that the new MAC OS, based upon MACH, would
>>have to include a shell.
>>
>>This may be slightly OT, but I don't like the way windows is going at
>>all, Microsoft seems to think it owns all your data, and I was
>>considering either going to Linux or the Apple. But Apple looked
>>viable only if it included a shell. Does the new MacOS include any
>>shells? And if so, which ones? Anybody know?
> 
>
> Yes, MacOS includes bash, tcsh, and zsh (but not ksh).  Bash is 
> necessary for the system to run -- like most Unix systems, many system 
> processes are shell scripts.

Yeah, but I was wondering if Apple had made it difficult to use and
hard to find. The Mac has always been violently [ :-) ]anti-CLI. And
since I do most of my work in a CLI, it never really interested me.

BTW, how does the MAC handle access? Is there a root account? I know
Mach is a unix, but Apple's ideas ain't very unix-like. How did they
work this?

> I think the paragraph that was quoted above was Apple's original ideal 
> for OS X, but they didn't make it all the way.  You can even find places 
> in their user documentation where the recommended action is to execute a 
> command in the Terminal.  For instance, their Network Utility provides a 
> GUI interface to tools like ping and traceroute, but the documentation 
> tells you to use the "man" command in a Terminal window to learn how to 
> interpret the output or use the underlying command directly (so you can 
> use options).

OK, that's encouraging.

Linux is still cheaper, but Apple's still in the running.

Rich






0
Rich
5/28/2004 6:25:24 PM
Bruce Barnett <spamhater95+U040528064519@grymoire.com> wrote:
> Christopher Browne <cbbrowne@acm.org> writes:
>
>> Or perhaps a Lisp system; one of the classic jokes is that of running
>> Emacs as the "operating system," and running it, instead of a shell,
>> would be a good example of this...
>
> It's no joke.
> When I first started work at my company (1988) several of the people
> were using Symbolics workstations. The entire system is based on Lisp.
>
> The concept of data and code being separate became blurred.
> Code modified and generated new code all the time.

The "is a joke" part is that people joke about running Emacs as the
"operating system."

If, instead of running some form of "rc.d", a Unix system 'booted up'
by invoking a Lisp instance (say, CMU/CL), then that would do things
controlled from there, well, that would be a way of doing a 'modern'
sort of Lisp Machine system.  It's not entirely pretty, alas...
-- 
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/unix.html
You know better than to trust a strange computer.
0
Christopher
5/28/2004 6:52:48 PM
Bob Kryger <NSbobkNS@panix.com> wrote:
> BUT, If I remember the boot sequence right, you COULD have a program 
> that is started via the inittab, and all other programs turned off, 
> including ttys and then not running any of the rcs, there for no telnet, 
> rsh, ssh etc.
> 
> So the kernel would boot, it would exec init, init runs this fictional 
> binary.  You could actually try this using runlevel 4, which is usually 
> unused.

Yes, you have invoke directly from /etc/inittab.  Even /etc/rc.d/rc.4 is
a shell script.  Time to time, Microsoft makes noise about having
dedicate "desktop" machine which will run only MS-Office suite, directly
from boot.  Superficially, they make sense, since typical office user
NEVER leaves Office applications.  But, I think Microsoft just wants to
get free PR at the expense of Linux. :-)

-- 
William Park, Open Geometry Consulting, <opengeometry@yahoo.ca>
Linux, Bash, Vim, TeX/LaTeX, Python, Mozilla, OpenOffice, Thin-Client
0
William
5/28/2004 7:30:15 PM
In article <40B77441.10003@yahoo.com>,
 Kevin Rodgers <ihs_4664@yahoo.com> wrote:

> joe@invalid.address wrote:
>  > Kevin Rodgers <ihs_4664@yahoo.com> writes:
>  >>I don't think he's asking for something that extreme; I think what he
>  >>means is the ability to run executables, but with no shell features or
>  >>the syntax that supports them:
>  >
>  > What does that mean? I'm having a hard time thinking of how that can
>  > be achieved without some kind of shell or writing a program that gets
>  > loaded apart from a shell somehow.
>  >
>  > If what you're suggesting is "some program which reads input from
>  > the user and executes programs", isn't that a shell?
> 
> Well, it's a command line interface.  But without file name patterns,
> variable and command substitution, pipes and redirection, functions and
> alises, etc. I wouldn't call it a shell.

Early Bourne shell didn't have functions or aliases, I believe (aliases 
showed up in csh first).  And I'll bet the Thompson shell was lacking 
other features that we consider normal these days.  On many (non-Unix) 
operating systems, file name patterns are implemented by the commands 
themselves calling a library function (analogous to glob()), and scripts 
are executed by an interpreter distinct from the interactive CLI (so the 
CLI might not implement variables or fancy control structures -- they 
would just be in the script interpreter).

The basic function of a shell is to provide a way for users to invoke 
programs interactively.  Everything else is just bells and whistles to 
support automation and other convenience features.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
5/28/2004 9:21:18 PM
In article <40B78414.2070103@somewhere.com>,
 Rich <someone@somewhere.com> wrote:

> > Yes, MacOS includes bash, tcsh, and zsh (but not ksh).  Bash is 
> > necessary for the system to run -- like most Unix systems, many system 
> > processes are shell scripts.
> 
> Yeah, but I was wondering if Apple had made it difficult to use and
> hard to find. The Mac has always been violently [ :-) ]anti-CLI. And
> since I do most of my work in a CLI, it never really interested me.

The Terminal application is in the Utilities folder rather than the main 
Applications folder, so it's not right in your face but it's not "hard 
to find" either.  Power users probably use lots of applications in 
Utilities.

> BTW, how does the MAC handle access? Is there a root account? I know
> Mach is a unix, but Apple's ideas ain't very unix-like. How did they
> work this?

There's a root account, but most users don't use it.  Applications that 
need privileged access (e.g. to install new applications or update the 
OS) make use of "sudo" internally -- the put up a dialogue that asks the 
user for their password.  The default sudoers file allows the "admin" 
group to use it, and typically the primary user of the machine is in 
this group (although for better security you should probably have a 
special admin userid, and login as that to perform administrative tasks).

Most of the stuff that makes the system Mac-like is just libraries on 
top of Unix and some device drivers (like support for Apple's HFS file 
system).  It's much the same way that X11 and GNOME are layered on top 
of traditional Unix systems.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
5/28/2004 9:30:54 PM
William Park wrote:
> Bob Kryger <NSbobkNS@panix.com> wrote:
> 
>>BUT, If I remember the boot sequence right, you COULD have a program 
>>that is started via the inittab, and all other programs turned off, 
>>including ttys and then not running any of the rcs, there for no telnet, 
>>rsh, ssh etc.
>>
>>So the kernel would boot, it would exec init, init runs this fictional 
>>binary.  You could actually try this using runlevel 4, which is usually 
>>unused.
> 
> 
> Yes, you have invoke directly from /etc/inittab.  Even /etc/rc.d/rc.4 is
> a shell script.  

True, but you can stop the execution of rc scripts by pulling out the 
appropriate line. In this case, on linux, you could disable the rc 
scripts by either commenting it out, or changing the 'action' to off. Do 
the same for mingetty and, to be complete, sysinit and now you have a 
runlevel that does absolutely nothing, ready for your made-to-order 
process. I would not be surprised if there were App boxes out there that 
actually worked this way.

Pretty cool I think.


> Time to time, Microsoft makes noise about having
> dedicate "desktop" machine which will run only MS-Office suite, directly
> from boot.  Superficially, they make sense, since typical office user
> NEVER leaves Office applications.  But, I think Microsoft just wants to
> get free PR at the expense of Linux. :-)
> 

At first look it makes sense, but after further thought I'm not sure. 
I've not been in an office, that actually had the need to run ONLY 
office suite. Besides, what harm would this concept do to Linux, you 
could do it there just as easily, maybe more so.

bk
0
Bob
5/30/2004 4:43:53 PM
Reply: