Hi everyone, Hans wrote me the following, but I'm unable to figure it out myself. The script "setuptex" (which is in fact not urgently needed as one can just as well export the right path, but it comes in handy) can be used in two ways: (a) . /path/to/context/tex/setuptex (b) . /path/to/context/tex/setuptex /path/to/context/tex The first approach only works if the shell interpreting setuptex knows where the sourced script is located. Currently the script uses the following code and works in Bash, KSH (and maybe some other shells as well, but I'm not sure which ones). if [ z"$BASH_SOURCE" != z ]; then SCRIPTPATH="$BASH_SOURCE" elif [ z"$KSH_VERSION" != z ]; then SCRIPTPATH="${.sh.file}" else SCRIPTPATH="$0" fi Hans had problems with Dash, however, I have no clue how to enable (a) in Dash. The (b) approach always works though, so in the worst case the answer to Hans would be "provide the path to your tex root, or write your own script with hardcoded path ;)", but if anyone has any clue if finding path to the executed script is possible in Dash or in any other POSIX-compatible way, please let me know. Mojca On Mon, Nov 19, 2012 at 10:31 AM, Hans Hagen wrote:
Hi Mojca,
One of the things you need to look into is the first-setup and setup tex scripts (just look at the dash issues thread) .. i have the impression that the setuptex script doesn't find its root (own) under dash because it has different $0 handling (dash is the debian variant of bash, so we're talking of debian installations)
Hans
Mojca,
I'm not sure that I understand the question.
1. dash (Debian version of the real 100% posix-compatible Borne shell)
but also /bin/sh on freebsd and other Unixes (BSD, sysV or POSIX).
It is the "least common denominator" for shell scripts on most (if not
all) unix-like systems, as far as I know.
2. $0 will give the the path of the script, unless it is called
as ./script or script (in the current directory). In this case it
will probably be "./script" or by "pathtoscript/script" in which case
it will return "pathtoscript/script". The current directory can then be
found by `pwd` or $PWD
3 Sourcing the script (not calling it as an executable) as
"source script" or ". script" will return as $0 "/bin/bash" or
"/usr/local/bin/bash" or "/bin/sh" or whatever shell is in use.
This is your problem, I believe.
There does not seem to be a way to determine the path to a script
under a Borne shell if the script is SOURCED and not EXECUTED.
Of course, a script that is executed runs a sub-shell and so this
cannot be used to set variables, even environmental variables, for the
calling shell.
Alan
On Wed, 21 Nov 2012 12:56:54 +0100
Mojca Miklavec
Hi everyone,
Hans wrote me the following, but I'm unable to figure it out myself. The script "setuptex" (which is in fact not urgently needed as one can just as well export the right path, but it comes in handy) can be used in two ways: (a) . /path/to/context/tex/setuptex (b) . /path/to/context/tex/setuptex /path/to/context/tex The first approach only works if the shell interpreting setuptex knows where the sourced script is located.
Currently the script uses the following code and works in Bash, KSH (and maybe some other shells as well, but I'm not sure which ones).
if [ z"$BASH_SOURCE" != z ]; then SCRIPTPATH="$BASH_SOURCE" elif [ z"$KSH_VERSION" != z ]; then SCRIPTPATH="${.sh.file}" else SCRIPTPATH="$0" fi
Hans had problems with Dash, however, I have no clue how to enable (a) in Dash. The (b) approach always works though, so in the worst case the answer to Hans would be "provide the path to your tex root, or write your own script with hardcoded path ;)", but if anyone has any clue if finding path to the executed script is possible in Dash or in any other POSIX-compatible way, please let me know.
Mojca
On Mon, Nov 19, 2012 at 10:31 AM, Hans Hagen wrote:
Hi Mojca,
One of the things you need to look into is the first-setup and setup tex scripts (just look at the dash issues thread) .. i have the impression that the setuptex script doesn't find its root (own) under dash because it has different $0 handling (dash is the debian variant of bash, so we're talking of debian installations)
Hans
On Wed, Nov 21, 2012 at 6:35 PM, Alan BRASLAU wrote:
3 Sourcing the script (not calling it as an executable) as "source script" or ". script" will return as $0 "/bin/bash" or "/usr/local/bin/bash" or "/bin/sh" or whatever shell is in use. This is your problem, I believe.
True. But Peter's idea is also not that bad. The drawback is that the distribution cannot be moved to a different directory then, but one could also have combination of both approaches somehow. Mojca
On Wed, Nov 21 2012, Mojca Miklavec wrote:
But Peter's idea is also not that bad. The drawback is that the distribution cannot be moved to a different directory then, but one could also have combination of both approaches somehow.
Is it worth the trouble to keep setuptex? Just saying "Please add ... to your PATH" should be enough IMO. -- Peter
On Wed, Nov 21, 2012 at 8:28 PM, Peter Münster
Just saying "Please add ... to your PATH" should be enough IMO.
We currently have the following wording: When you want to use context, you need to initialize the tree by typing: . /path/to/context/tex/setuptex in your shell or add "/path/to/context/tex/texmf-osx-64/bin" to PATH variable if you want to set it permanently. This can usually be done in .bashrc, .bash_profile (or whatever file is used to initialize your shell). But we could remove the part about setuptex and be more explicit by writing down export PATH=... ;) The reason why I use/like setuptex is because I'm nowadays mostly working with TeX Live 2012 and only switch to distribution when I need that (a new feature or when I want to test something). And it far easier to use tab-completion to point to the desired setuptex than to write an explicit "export PATH=..." every time a shell is started. I could of course write my own "distribution switcher". Mojca
On 11/21/2012 8:28 PM, Peter Münster wrote:
On Wed, Nov 21 2012, Mojca Miklavec wrote:
But Peter's idea is also not that bad. The drawback is that the distribution cannot be moved to a different directory then, but one could also have combination of both approaches somehow.
Is it worth the trouble to keep setuptex? Just saying "Please add ... to your PATH" should be enough IMO.
I often use it. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 11/22/2012 10:18 AM, Hans Hagen wrote:
On 11/21/2012 8:28 PM, Peter Münster wrote:
On Wed, Nov 21 2012, Mojca Miklavec wrote:
But Peter's idea is also not that bad. The drawback is that the distribution cannot be moved to a different directory then, but one could also have combination of both approaches somehow.
Is it worth the trouble to keep setuptex? Just saying "Please add ... to your PATH" should be enough IMO.
I often use it.
Me too, I have quite a bunch of scripts that are distributed to online servers that do not all have the same architecture. Best wishes, Taco
On Thu, 22 Nov 2012 10:21:28 +0100
Taco Hoekwater
On 11/22/2012 10:18 AM, Hans Hagen wrote:
On 11/21/2012 8:28 PM, Peter Münster wrote:
On Wed, Nov 21 2012, Mojca Miklavec wrote:
But Peter's idea is also not that bad. The drawback is that the distribution cannot be moved to a different directory then, but one could also have combination of both approaches somehow.
Is it worth the trouble to keep setuptex? Just saying "Please add ... to your PATH" should be enough IMO.
I often use it.
Me too, I have quite a bunch of scripts that are distributed to online servers that do not all have the same architecture.
Sourcing setuptex (. pathtocontext/setuptex) will fail to find and thus modify the path under pure Borne shells and their equivalents. It will work just fine under bash, ksh (but sourcing the script will fail totally under csh and tcsh). Executing the script (pathtocontext/setuptex) should run correctly under all shells but will in all cases fail to set the path. My suggestion is simply to modify the message printed at the end: In the case of an execution rather than a sourcing, or in the case of sourcing under a Borne shell, the script could instruct the user to manually modify the path. In the other case, it could set the path. Alan
participants (5)
-
Alan BRASLAU -
Hans Hagen -
Mojca Miklavec -
Peter Münster -
Taco Hoekwater