TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: word of the day From:Ned Bedinger <doc -at- edwordsmith -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 07 Dec 2009 00:44:29 -0800
Robert Lauriston wrote:
> So in Unix-speak a shell that's being driven by a script that doesn't
> prompt for user input is a "non-interactive shell"? I guess that makes
> sense since it's referring to an instance of the shell.
Just for the heck of it, you could have a non-interactive shell spawn an
interactive sub-shell, if you wanted to, More about subshells (not sure
if it contributes to an answer for the OP, I wasn't paying attention 8?).
>
> In conventional Windows-speak, the default shell for Windows XP is
> explorer.exe. There's also the DOS-like command prompt cmd.exe and
> there are lots of alternative shells.
Considering Unix shells, it seems like there must be architectural
considerations about what a shell is. I want there to be a better
definition than "has a prompt", as was suggested in the first link above.
Anyway, I thought what you said about explorer.exe was an interesting
proposition so I fiddled around with it (%systemroot\explorer.exe).
A few weird things turned up, things that might reveal something more
about Windows architecture to someone who "really gets it" (alas, I
don't spend much attention on it). Here's my notes. have fun.
If I launch a few Windows apps in XP--let's say Windows File Explorer
and Internet Explorer--and then kill off explorer.exe, the desktop
disappears because I just killed it, and File Explorer disappears,
presumably because it was running in the desktop shell I killed. Yet
Internet Explorer keeps running.
So maybe Internet Explorer runs directly on the XP OS, I don't think
(ha) anything about this would contradict the claim that explorer.exe is
a shell. But to me (not exceptionally knowledgeable) a classic shell
serves as the UI to the OS, sort of like the way the 1explorer.exe
desktop is the UI to XP, but unlike the explorer.exe shell, everything
you do in Unix is in the shell--you can't do anything outside of it the
way you can run apps in XP outside of the Desktop "shell". So the
Desktop doesn't seem to be 'the shell' since some apps run outside of it.
In another experiment, I found that, as expected, if I kill the
explorer.exe process, then start %systemroot%\explorer.exe, it restarts
the desktop and puts the GUI back to normal. No guarantees that Windows
will be stable after mucking with the running desktop, but it does look
normal after killing and restarting explorer.exe.
But then I found that if the desktop is running, and I 'run'
explorer.exe again, it starts an instance of File Explorer. Feh. Why
File Explorer? Why? Why?? Why?? Is explorer.exe an application AND
something else too, like a Windows service or something? Yeesh, it
overloads my mind trying to discern the XP shell.
So that is my finding in this experiment: Explorer.exe is the binary
that creates the desktop. It appears in Task Manager only as a process
(named explorer.exe) on the Process tab. It does not show up on the
Application tab. But explorer.exe, when it creates File Explorer,
appears on the Application tab in Task Manager, and doesn't seem to have
a process (at least, it isn't named "explorer.exe").
I prefer to think of shells simply as command shells with prompts, as
explained in the link above. But admittedly, computing has come a long,
long way since Unix designers wanted shells. Just think, you could run
another OS in a virtual machine as your shell! The concept back then was
clear, fertile ground for advancing productivity by creating shells with
features you wanted at the command line, shells that worked the way you
liked, and shells with advanced features like built-in compilers or
interpreters, so for example you could execute 'C' code in the C shell.
I'm not sure it is very useful (but it is tempting) to think of
environments as shells, not much beyond that earlier Unix text-mode
context, where a command line had a prompt and a shell command line
looked a lot the same, represented a new instance of the OS running, had
rules about inheritance, was extensively configurable, etc etc etc.
Have a lot of fun,
Ned Bedinger
doc -at- edwordsmith -dot- com
>
> On Thu, Dec 3, 2009 at 4:11 PM, Laura Lemay <lemay -at- lauralemay -dot- com> wrote:
>> On Dec 3, 2009, at 4:04 PM, Robert Lauriston wrote:
>>
>>> "Interactive shell"? A shell is by definition interactive, no?
>> No, shell scripts are not interactive. Unless they have a menu
>> system. :)
>>
>> "Interactive shell" is a Unix term, BTW, and refers specifically to an
>> actual shell (bash, csh, tcsh, etc). The only shell in Windows is DOS.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-