[cl-debian] Bug#384697: cl-launch: need to modify script variables without touching the script

[Luca Capello]

tags 384697 + patch
thanks

Hello Faré!

On Sat, 26 Aug 2006 06:08:39 +0200, Faré wrote:
> I'm not sure we either need or want a /etc/cl-launchrc or a
> ~/.cl-launchrc.

I still think that's the way to go, but obviously we need more
feedbacks from the other CL-Debian developers/users (especially Peter
and René).  Xavier, this is the reason I explicitly cc:ed you again, I
hope you don't mind :-)

The attached patch is a very simple support for ~/.cl-launchrc, based
on the CL-Launch available in Debian, thus 1.85-1.  To apply it:

  $ [save the patch somewhere]
  $ cp /usr/share/common-lisp/source/cl-launch/wrapper.sh ~/
  $ patch wrapper.sh < /path/to/the/patch
  $ [modify your CL-Launch script to call include ~/wrapper.sh instead
    of the /usr/share/common-lisp/source/cl-launch/wrapper.sh]

~/.cl-launchrc is a shell file, with the following structure:

  [value of $SOFTWARE_SYSTEM in the CL-Launch script] = \
    [Common Lisp implementation to be used]

I assume that the value of $SOFTWARE_SYSTEM will always be the name of
the script, i.e. /usr/bin/$SOFTWARE_SYSTEM.  Thus, for StumpWM would
be something like the following:

  stumpwm=sbcl

ATM the patch is quite dirty, because it uses grep and the BASH
parameter substitution to assign the value, while the same function
should be very simple as:

  check_lisp_variable () {
    test -r /etc/cl-launchrc && . /etc/cl-launchrc
    test -r "$HOME/.cl-launchrc" && . "$HOME/.cl-launchrc"
    test -n ${SOFTWARE_SYSTEM} && LISP=${SOFTWARE_SYSTEM}
  }

The last line is obviously fault, what I'd like to do is:

  if the variable called with the name of the value of
  $SOFTWARE_SYSTEM is not-empty set the LISP variable to that value

Unfortunately, I don't know how to do it in shell language, I quickly
and unsuccessfully read `man bash`, so I post here in case someone
with more shell skills would help.

> After all, the user (or root) may already export the variable $LISP
> to override things at runtime (or at dump time), whatever the --lisp
> or $LISPS variable be, unless explicitly prevented with a --wrap
> argument (or a resetting of $LISP), and I think that's all we need.

If we ship a CL-Launch script I'd like to avoid special forms like:

  $ LISP=sbcl /usr/bin/stumpwm
  $ /usr/bin/stumpwm --lisp sbcl

> As for stumpwm, note that I prefer the more versatile --init
> argument:
>   '(stumpwm:stumpwm (cl-launch:getenv "DISPLAY"))'
> to a hardcoded :0.

OK, I noticed it and I completely agree, as this is The Right Thing™,
because we can't assume $DISPLAY always :0.0.

> If multiple dumped versions are wanted, they should each have a
> different name, and the main script would select amongst them.

Well, for sure I'm not going to support multiple versions (would be
them dumped images or not).  IMHO, if a Debian package ships a
CL-Launch script at /usr/bin/$SOFTWARE_SYSTEM, this should be the more
generic possible, i.e. $LISPS should contains all the Common Lisp
implementation that the _Debian package_ support.

Thx, bye,
Gismo / Luca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: home_cl-launchrc_gismo-20060826.patch
Type: text/x-patch
Size: 595 bytes
Desc: very brutal ~/.cl-launchrc support
URL: <https://mailman.common-lisp.net/pipermail/cl-debian/attachments/20060826/e0d20e2d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-debian/attachments/20060826/e0d20e2d/attachment.sig>