Re: Emacs Environment Variables

[Tim X <timx@nospam.dev.null>]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 27.11.2007 um 09:03 schrieb Tim X:
>
>> I don't want to have to know two shells, one for interactive work  and
>> one
>> for scripting.
>
>
> So you're boiling your eggs with a hammer?
>

No . Of all the cliches you possibly could have used, that one makes the
least sense of all. maybe its a language/translation issue?

> For me it's not that complicated to write in German, English, Perl,  awk,
> Bourne sh, tcsh, ksh. ELisp and French are a bit more  complicated, I
> admit. 

Well maybe your just smarter than me. I find it takes me a bit of time to
adjust when the languages don't differ significantly. I have no problems
moving from sh to perl because they are so different, but remembering
idiosyncratic differences in quoting, redirection alias definitions and
command substitution in two languages that only differ in syntactic sugar
is a pain. then again, you say you find elisp to be one of the harder ones,
yet I find lisp style languages really easy because they have such simple
and consistent syntax (knowing all the available functions is a bit harder,
but you can look those up. Inconsistencies in syntax, like do-done vs if-fi
or export-setenv are more irritating).

However, the real point is possibly better explained this
way....

I live in a world where everyone speaks english. There are also some other
languages, but everyone who speaks these other languages also speaks fluent
english. (substitute whatever language you like for 'english', it doesn't matter
as long as everyone knows it)

sometimes, I just want to communicate really simple things - "Barman, can I
have a beer" and as I know he speaks english and don't know what other
language he speaks, it makes sense for me to ask him in english. I return
to my table of friends. We are discussing the pros and cons of Marxism and
debating if he was right or wrong. All of my friends are from various parts
of the world and some of them speak other languages, but they also all
speak english and therefore I use english to communicate some of the more
complex abstract concepts and ideas I want to express. This is not a
problem - I have the necessary expressive power.

In this world, why would I want'need to learn another language. I might do
it for fun, but I certanly don't need to. Substitute bash for english and
the same holds. If I want to be really certain I'm understood, I'll stick
to sh, which is available on every Unix/Gnu Linux system I've ever
seen. I don't want to learn a language just for fun - they are
just my tools that allow me to do what I need/want to do, so I'm not
interested in learning another language - particularly one that is nearly
the same as the one I already know and doesn't provide me with any
additional expressive power (or worse, is likely to be confusing or
inconsistent because its almost the same, but not quite i.e. csh).

A bit too complicated is definitely Bash with  its too many modes of
> operation. Before I start thinking in which  circumstances a Bash script
> might be used and how I could prevent  failure, I better switch to another
> language that is failsafe.

I don't see this compicated maze of operation modes you seem to think exist
and will make your scripts break or fragile. Care to provide an example?
In fact, I'm even confused by what you mean by too many
modes. Essentially, bash has two modes - call it as 'sh' and it behaves
like the traditional bourne shell. Call it as /bin/bash and you get the
more recent or additional functionality that it has.

Are the 'modes' you refer to the distinction (ba)sh makes between
login, interactive and non-interactive shells? If so, I think your seeing
complexity where none exists. furthermore, most shells (including csh and
tcsh) also make a distinction, though it could be argued that (ba)sh goes
one step further by making a clearer distinction between login interactive
and just interactive shells. all of these shells have files that are
sourced for every shell (bashrc, cshrc etc) and login shells (bash_profile
and csh.login). It may be that the manual confuses things because the shell
has slightly different initialisation files depending on whether it is
called as sh or bash, but thats no more complex than tcsh behavior with
respect to .cshrc, .tcshrc  and .login. 

I would agree that the distinction between interactive and non-interactive
or login interactive and interactive are less important these days than
they use to be when processors were slower and memory was expensive. Back
then, you really didn't want your shell being slowed down by initialising
environment variables that were irrelevant, such as setting the prompt
variables for non-interactive shells or using up valuable scarce resources
such as memory to hold env vars you didn't need. These days, this is less
important. Whatever the case, you pretty much have only two real types,
interactive and on-interactive. In 20 years of writing shell scripts, I've
not run into any complications in this area using sh or bash.

Lets see some examples of these problems you refer to that arise from this
complexity of modes and maybe an explination of what these modes are you
refer to.

Tim

-- 
tcross (at) rapttech dot com dot au