Skip to Content.
Sympa Menu

sm-grimoire-bugs - [SM-Grimoire-Bugs] [Bug 11759] New: profile script lc.sh contains non-portable sh

sm-grimoire-bugs AT lists.ibiblio.org

Subject: SourceMage Grimoire Bug List

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-grimoire-bugs AT lists.ibiblio.org
  • Subject: [SM-Grimoire-Bugs] [Bug 11759] New: profile script lc.sh contains non-portable sh
  • Date: 4 May 2006 08:16:02 -0000

http://bugs.sourcemage.org/show_bug.cgi?id=11759

Summary: profile script lc.sh contains non-portable sh
Product: Codex
Version: test grimoire
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: libs
AssignedTo: sm-grimoire-bugs AT lists.ibiblio.org
ReportedBy: sqweek AT gmail.com


Exhibit A:
| if [[ -n ${!1} ]]
I think ${!1} (which is used to look up the value of the variable whose name
is
in $1 - eg if $1==USER, ${!1}==sqweek) is a bashism. I don't really have
anything concrete (how come anything POSIX/ANSI/ISO is so damn hard to find on
the 'net), but the syntax doesn't appear to be mentioned in any of:
http://docs.hp.com/en/B2355-90690/sh-posix.1.html
http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html
(hm, i just found an interesting thread
http://lists.debian.org/debian-devel/2000/10/msg00498.html which suggests the
opengroup link IS the posix spec)
zsh doesn't support this syntax either, which is the main reason this has
been
caught.

Exhibit B:
| LOCALE_VARS="LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE \
| LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME \
| LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_ALL"
|
| for i in $LOCALE_VARS
| do
| export_if_set "$i"
| done

Actually this is fine sh, I think. zsh is the problem this time in that by
default it doesn't perform word splitting on the expansion of variables (so
instead of 13 iterations through the loop with $i as LANG then LC_ALL etc, zsh
just does one iteration with $i as the entire LOCALE_VARS string).

There are portable constructs between zsh and bash, at least, and I'll submit
an lc.sh that I've tested in both, but this does raise the issue about what to
do about shells with less mainstream syntax (fish springs to mind, tcsh i'm
not
sure about).
The most obvious solution is to provide foo.sh foo.bash foo.fish foo.tcsh
files
for profile scripts. Which appears to be a lot more work, but considering the
nature of profile scripts (which generally just add to the path or set
environment variables) you could probably get away with defining a couple of
abstract commands for use in profiles, and then have an implementation for
these
commands for each shell, allowing profile scripts to be generated on the fly.
On
the other hand, brute force is probably a lot simpler ;)
Even after the scripts are generated though, there is still complication in
this approach with respect to when the profile scripts should be installed.
eg,
I cast sdl which installs sdl.sh, then I cast fish - now we also need sdl.fish
to be installed...

Fun!

--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



  • [SM-Grimoire-Bugs] [Bug 11759] New: profile script lc.sh contains non-portable sh, bugzilla-daemon, 05/04/2006

Archive powered by MHonArc 2.6.24.

Top of Page