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

Hello! On Sat, 26 Aug 2006 18:50:40 +0200, Luca Capello wrote:

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:

It was quite simple, just putting two ! (and I'd like to thanks __dave@irc.freenode.net for his support). The attached patch is tested on cl-launch_1.85-1, but it's generated against cl-launch_1.86 as at [1]. Comments? Thx, bye, Gismo / Luca Footnotes: [1] http://fare.tunes.org/files/cl-launch/

Due to popular request, I am working on an optional /etc/cl-launchrc feature for cl-launch. Because I allow a --no-rc option (that is enabled by default for me, you can use --rc by default), the contents of these file will be read *after* the option processing. A cl-launchrc file may contain statements such as: system_preferred_lisps stumpwm cmucl sbcl clisp system_preferred_lisps exscribe clisp cmucl Then remains the question of whether or not the statements should override a user-specified --lisps option. My current feeling is "yes, but issue a warning on stderr". Also, the preferrence happens at script-creation time. At runtime, the variable $LISP is still all that matters -- should it not? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Clairvoyant, n.: A person, commonly a woman, who has the power of seeing that which is invisible to her patron -- namely, that he is a blockhead. -- Ambrose Bierce

Hello! On Wed, 30 Aug 2006 01:38:30 +0200, Faré wrote:

Due to popular request, I am working on an optional /etc/cl-launchrc feature for cl-launch. [...] Also, the preferrence happens at script-creation time. At runtime, the variable $LISP is still all that matters -- should it not?

I tested your cl-launchrc feature and indeed it works as expected, but, as you wrote, at script-creation time. I think you and I are trying to solve a different problem: IMHO it's not worth supporting cl-launchrc at script-creation time, as per the following example. I, as the StumpWM maintainer, provide a general /usr/bin/stumpwm (which is a CL-Launch script, with LISPS="sbcl clisp"). Then, Joe User launches StumpWM and discovers that instead of his preferred Common Lisp (which turns out to be CLisp), the script uses SBCL (because it's the first option and it's available). So, Joe reads the StumpWM README.Debian where he finds that he can creates his own ~/bin/stumpwm via a /usr/share/doc/stumpwm/create-stumpwm-binary (provided by the StumpWM Debian package, calling `cl-launch --rc` and creating binaries in ~/bin/), specifying CLisp in his ~/.cl-launchrc. This situation is very similar to copying /usr/bin/stumpwm and modifying the LISPS variable. If a lot of CL-Launch depending packages acts like the above example, Joe User will have a crowded ~/bin/, which is something that I don't really like. And which is the "problem" I'm trying to solve. In my scenario, in fact, different CL-Launch scripts end to have only one configuration file, well, two (one general and one user-specific), instead of filling ~/bin. I'll investigate with the problem you arose in your previous posts (e.g. the --dump behavior), but I hope I have better explained my point :-) Thx, bye, Gismo / Luca

I'm not sure we either need or want a /etc/cl-launchrc or a ~/.cl-launchrc. 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. I second this. As for stumpwm, note that I prefer the more versatile --init argument: '(stumpwm:stumpwm (cl-launch:getenv "DISPLAY"))' to a hardcoded :0. Oh nice enhancement ! I did not know I could do this. Thank you. -- Xavier