From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: Emacs Environment Variables Date: Wed, 28 Nov 2007 19:55:39 +1100 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <873auqzr3o.fsf@lion.rapttech.com.au> References: <7e3068b0-defa-4b37-9092-182b521f5f50@e23g2000prf.googlegroups.com> <3568102A-B060-4D1F-B7B5-7944386B07A9@Web.DE> <20071124124821.GA5409@ono.com> <87ir3qzw3m.fsf@lion.rapttech.com.au> <877ik4yv1g.fsf@lion.rapttech.com.au> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196248772 5659 80.91.229.10 (28 Nov 2007 11:19:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2007 11:19:32 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Nov 28 12:25:12 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from [129.240.10.42] (helo=mail-forward.uio.no) by dough.gmane.org with esmtp (Exim 4.50) id 1IxKJU-00013g-94 for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Nov 2007 11:38:40 +0100 Original-Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IxJQx-00030n-2r for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Nov 2007 10:42:19 +0100 Original-Received: from lists.gnu.org ([199.232.76.165]) by mail-mx4.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxJQh-0007gO-9p for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Nov 2007 10:42:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxJPh-0001op-BC for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Nov 2007 04:41:01 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!sn-xt-sjc-02!sn-xt-sjc-07!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:Keq+qAK9zfyEUqHvZECdQwMBeiY= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 102 Original-Xref: shelby.stanford.edu gnu.emacs.help:154190 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org X-UiO-SPF-Received: Received-SPF: pass (mail-mx4.uio.no: domain of gnu.org designates 199.232.76.165 as permitted sender) client-ip=199.232.76.165; envelope-from=help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org; helo=lists.gnu.org; X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-1.0, required=5.0, autolearn=disabled, RCVD_IN_DNSWL_LOW=-1) X-UiO-Scanned: 7748C28C02A45AC7D19F3352A6B195EF2CF0FD5B X-UiO-SPAM-Test: remote_host: 199.232.76.165 spam_score: -9 maxlevel 200 minaction 2 bait 0 mail/h: 26 total 27880 max/h 424 blacklist 0 greylist 0 ratelimit 0 Xref: news.gmane.org gmane.emacs.help:49608 Archived-At: Peter Dyballa 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