SourceMage Grimoire Bug List

[bugzilla-daemon AT bugs.sourcemage.org]

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.