From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7807 invoked by alias); 22 Dec 2008 15:20:45 -0000 Received: (qmail 7796 invoked by uid 22791); 22 Dec 2008 15:20:44 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.173) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Dec 2008 15:19:58 +0000 Received: by wf-out-1314.google.com with SMTP id 28so2050671wfc.20 for ; Mon, 22 Dec 2008 07:19:57 -0800 (PST) Received: by 10.142.230.7 with SMTP id c7mr2725988wfh.45.1229959196966; Mon, 22 Dec 2008 07:19:56 -0800 (PST) Received: by 10.143.1.8 with HTTP; Mon, 22 Dec 2008 07:19:56 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 15:20:00 -0000 From: "Mark J. Reed" To: cygwin@cygwin.com Subject: Re: Unusual environemtal variables In-Reply-To: <200812211606.mBLG6LX2014401@beta.mvs.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <494BA56A.7070009@byu.net> <200812211606.mBLG6LX2014401@beta.mvs.co.il> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2008-12/txt/msg00545.txt.bz2 Eric Blake: > That is inherently non-portable. POSIX states that "Other characters may > be permitted by an implementation; applications shall tolerate the > presence of such names," but does not require applications to be able to > create such names. Right. Ehud Karni: > This behavior (accepting names of only ASCII Alpha and _) is a bash self > imposed limitation. If you use csh (or tcsh) names with other characters > are supported too. Somewhat overstated. None of the shells I know of will let you set a shell variable/parameter whose name doesn't match the standard ASCII identifier pattern (initial letter or underscore followed by letters, underscore, or digits): bash$ @foo=bar bash: @foo=bar: command not found bash$ export @foo=bar bash: export: `@foo=bar': not a valid identifier tcsh% set @foo=bar set: Variable name must begin with a letter. Since in sh/bash/ksh, the only way to set an environment variable is to first set a shell variable and then "export" it into the environment, the above restriction on shell variables becomes a restriction on environment variables, too. Whereas in *csh, shell variables and environment variables are set via different commands, so the restriction on shell variables doesn't extend to the environment: tcsh% setenv @FOO bar tcsh% Even in the *csh shells, however, environment variables are still expanded via the same mechanism as shell variables, so the value of one with a non-portable name is not accessible directly: tcsh% echo $@FOO Illegal variable name. tcsh% echo ${@FOO} Illegal variable name. You have to use indirection, e.g.: tcsh% setenv | awk -F= '($1=="@FOO") {print $2}' bar At least ash and bash leave variables with non-portable names in the environment to pass on to child processes; it looks like zsh and ksh (both AT&T and PD versions) strip them from the environment entirely: env @FOO=bar ksh ksh$ env | grep @FOO ksh$ None of the foregoing is unique to Cygwin, however. The intersection is that there seem to be Windows applications which expect to inherit environment variables with non-POSIX names, and Cygwin users such as Steve who wish to launch such programs from the Cygwin environment. The logical solution there is to do as Eric suggested and use env, although if it's a simple script (or one you consider worth the porting effort) you could also rewrite it in csh instead. -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/