[zsh] full path of a script

Hello.

currently use the following code to get the full path of the currently
running script:

pushd "$(dirname ${0})";
typeset -r My_Dir=$(pwd);
popd;

But somehow I think there must be a better way. So is there?

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: full path of a script

On Sep 24, 8:11 am, Martin Krischik
wrote:
> Hello.
>
> currently use the following code to get the full path of the currently
> running script:
>
> pushd "$(dirname ${0})";
> typeset -r My_Dir=$(pwd);
> popd;
>
> But somehow I think there must be a better way. So is there?
>
> Martin
> --
> mailto://krisc...@users.sourceforge.net
> Ada programming at:http://ada.krischik.com

I think you want:
${variable%/*}

>TEST="/home/unxsa/csm/gdsh"
>echo ${TEST%/*}
/home/unxsa/csm

Miles

Re: full path of a script

Miles schrieb:
> On Sep 24, 8:11 am, Martin Krischik
> wrote:
>> Hello.
>>
>> currently use the following code to get the full path of the currently
>> running script:
>>
>> pushd "$(dirname ${0})";
>> typeset -r My_Dir=$(pwd);
>> popd;
>>
>> But somehow I think there must be a better way. So is there?
>>
>> Martin
>> --
>> mailto://krisc...@users.sourceforge.net
>> Ada programming at:http://ada.krischik.com
>
> I think you want:
> ${variable%/*}
>
>> TEST="/home/unxsa/csm/gdsh"
>> echo ${TEST%/*}
> /home/unxsa/csm

Interesting. However it won't work in all thinkable cases. Try:

echo 'echo ${0%/*}' >"/home/unxsa/csm/test.zsh"
chmod +x /home/unxsa/csm/test.zsh
cd /home
../unxsa/csm/test.zsh

see what I mean? I guess what I am relay looking for is a way to convert
a relative path into an absolute path. The other option which I can
think of it:

typeset -r My_Dir="$(pwd)/$(dirname ${0})";

but that might leave me with ugly embedded "/../" or "/./".

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: full path of a script

On Sep 24, 9:08 am, Martin Krischik
wrote:
> Miles schrieb:
>
>
>
> > On Sep 24, 8:11 am, Martin Krischik
> > wrote:
> >> Hello.
>
> >> currently use the following code to get the full path of the currently
> >> running script:
>
> >> pushd "$(dirname ${0})";
> >> typeset -r My_Dir=$(pwd);
> >> popd;
>
> >> But somehow I think there must be a better way. So is there?
>
> >> Martin
> >> --
> >> mailto://krisc...@users.sourceforge.net
> >> Ada programming at:http://ada.krischik.com
>
> > I think you want:
> > ${variable%/*}
>
> >> TEST="/home/unxsa/csm/gdsh"
> >> echo ${TEST%/*}
> > /home/unxsa/csm
>
> Interesting. However it won't work in all thinkable cases. Try:
>
> echo 'echo ${0%/*}' >"/home/unxsa/csm/test.zsh"
> chmod +x /home/unxsa/csm/test.zsh
> cd /home
> ./unxsa/csm/test.zsh
>
> see what I mean? I guess what I am relay looking for is a way to convert
> a relative path into an absolute path. The other option which I can
> think of it:
>
> typeset -r My_Dir="$(pwd)/$(dirname ${0})";
>
> but that might leave me with ugly embedded "/../" or "/./".
>
> Martin
> --
> mailto://krisc...@users.sourceforge.net
> Ada programming at:http://ada.krischik.com

This works in the basic case:

$PWD/${0#./}

Miles

Re: full path of a script

"Martin Krischik" schrieb im Newsbeitrag
news:46f7c4f7$1@news.post.ch...
> Miles schrieb:
>> On Sep 24, 8:11 am, Martin Krischik
>> wrote:
>>> Hello.
>>>
>>> currently use the following code to get the full path of the currently
>>> running script:
>>>
>>> pushd "$(dirname ${0})";
>>> typeset -r My_Dir=$(pwd);
>>> popd;
>>>
>>> But somehow I think there must be a better way. So is there?
>>>
>>> Martin
>>> --
>>> mailto://krisc...@users.sourceforge.net
>>> Ada programming at:http://ada.krischik.com
>>
>> I think you want:
>> ${variable%/*}
>>
>>> TEST="/home/unxsa/csm/gdsh"
>>> echo ${TEST%/*}
>> /home/unxsa/csm
>
> Interesting. However it won't work in all thinkable cases. Try:
>
> echo 'echo ${0%/*}' >"/home/unxsa/csm/test.zsh"
> chmod +x /home/unxsa/csm/test.zsh
> cd /home
> ./unxsa/csm/test.zsh
>
> see what I mean? I guess what I am relay looking for is a way to convert
> a relative path into an absolute path. The other option which I can
> think of it:
>
> typeset -r My_Dir="$(pwd)/$(dirname ${0})";
>
> but that might leave me with ugly embedded "/../" or "/./".
You'd need to check
whether $0 starts with /, if so, everything is fine and you're done
else if it starts with ., prepend $(PWD) and (optionally) find a way to
normalize that (e.g.: cd $(dirname $(pwd)/$0;pwd)
else search $PATH until you find $0

Bye, Jojo

Re: full path of a script

> You'd need to check
> whether $0 starts with /, if so, everything is fine and you're done
> else if it starts with ., prepend $(PWD) and (optionally) find a way to
> normalize that (e.g.: cd $(dirname $(pwd)/$0;pwd)
I agree 100%.

> else search $PATH until you find $0
No. There is no guarantee that the script is in your path.


Although, I am curious, why does the script need to know its own full
path?

Miles

Re: [zsh] full path of a script

On Mon, 24 Sep 2007 15:11:51 +0200, Martin Krischik
wrote:
>
>
> Hello.
>
> currently use the following code to get the full path of the currently
> running script:
>
> pushd "$(dirname ${0})";
> typeset -r My_Dir=$(pwd);
> popd;
>
> But somehow I think there must be a better way. So is there?
>
> Martin

I think the better way in Unix is not to make your script depend on
knowing its own location, but some ideas on this topic were discussed
recently in this newsgroup.


--
Romance, like alcohol, should be enjoyed, but should not be allowed to
become necessary.
-- Edgar Friedenberg

Re: [zsh] full path of a script

Bill Marcum wrote:

> On Mon, 24 Sep 2007 15:11:51 +0200, Martin Krischik
> wrote:
>>
>>
>> Hello.
>>
>> currently use the following code to get the full path of the currently
>> running script:
>>
>> pushd "$(dirname ${0})";
>> typeset -r My_Dir=$(pwd);
>> popd;
>>
>> But somehow I think there must be a better way. So is there?
>>
>> Martin
>
> I think the better way in Unix is not to make your script depend on
> knowing its own location, but some ideas on this topic were discussed
> recently in this newsgroup.

There are additional support files in same directory. Now that alone would
not be a problem. The script also make a pushd into another place from
where it tries to access the named file.

As said: I have a working solution. I was just wonder if there is a better
way. On windows I would use either %@FULL [1] or %@TRUENAME [2] and I am
kind of supprised that Unix has nothing in that direction.

Martin

[1] http://www.jpsoft.com/help/index.htm?f_full.htm
[2] http://www.jpsoft.com/help/index.htm?f_truename.htm

--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: full path of a script

"Miles" schrieb im Newsbeitrag
news:1190646536.535556.17840@19g2000hsx.googlegroups.com...
>> You'd need to check
>> whether $0 starts with /, if so, everything is fine and you're done
>> else if it starts with ., prepend $(PWD) and (optionally) find a way to
>> normalize that (e.g.: cd $(dirname $(pwd)/$0;pwd)
> I agree 100%.
>
>> else search $PATH until you find $0
> No. There is no guarantee that the script is in your path.
I think that a script, if not called with an absolute or relative pathname
would be searched for in PATH, just like every other executable.

Bye, Jojo

Re: full path of a script

On Sep 24, 12:42 pm, Martin Krischik
wrote:
> Bill Marcum wrote:
> > On Mon, 24 Sep 2007 15:11:51 +0200, Martin Krischik
> > wrote:
>
> >> Hello.
>
> >> currently use the following code to get the full path of the currently
> >> running script:
>
> >> pushd "$(dirname ${0})";
> >> typeset -r My_Dir=$(pwd);
> >> popd;
>
> >> But somehow I think there must be a better way. So is there?
>
> >> Martin
>
> > I think the better way in Unix is not to make your script depend on
> > knowing its own location, but some ideas on this topic were discussed
> > recently in this newsgroup.
>
> There are additional support files in same directory. Now that alone would
> not be a problem. The script also make a pushd into another place from
> where it tries to access the named file.
>
> As said: I have a working solution. I was just wonder if there is a better
> way. On windows I would use either %@FULL [1] or %@TRUENAME [2] and I am
> kind of supprised that Unix has nothing in that direction.
>
> Martin
>
> [1]http://www.jpsoft.com/help/index.htm?f_full.htm
> [2]http://www.jpsoft.com/help/index.htm?f_truename.htm
>
> --
> mailto://krisc...@users.sourceforge.net
> Ada programming at:http://ada.krischik.com

I don't know if this works for everyone: our UNIX admin scripts are
mainly in one directory. It happens to be /home/unxsa/bin - unx is
UNIX and sa for System Administration. That doesn't really matter. So,
I have an environment variable defined in /etc/profile:

UNIX_SYSTEM_DIRECTORY=/home/unxsa

I also define: SCRDIR=$UNIX_SYSTEM_DIRECTORY/bin

Then if I ever need to know where the scripts are, I do.

Is this just naive?

Miles

Re: [zsh] full path of a script

Martin Krischik wrote:
> Bill Marcum wrote:
>
>
>>On Mon, 24 Sep 2007 15:11:51 +0200, Martin Krischik
>> wrote:
>>
>>>
>>>Hello.
>>>
>>>currently use the following code to get the full path of the currently
>>>running script:
>>>
>>>pushd "$(dirname ${0})";
>>> typeset -r My_Dir=$(pwd);
>>>popd;
>>>
>>>But somehow I think there must be a better way. So is there?
>>>
>>>Martin
>>
>>I think the better way in Unix is not to make your script depend on
>>knowing its own location, but some ideas on this topic were discussed
>>recently in this newsgroup.
>
>
> There are additional support files in same directory. Now that alone would
> not be a problem. The script also make a pushd into another place from
> where it tries to access the named file.
>
> As said: I have a working solution. I was just wonder if there is a better
> way. On windows I would use either %@FULL [1] or %@TRUENAME [2] and I am
> kind of supprised that Unix has nothing in that direction.
>
> Martin
>
> [1] http://www.jpsoft.com/help/index.htm?f_full.htm
> [2] http://www.jpsoft.com/help/index.htm?f_truename.htm
>
Check out the ksh type command and dirname its results.

Bill Seivert

Re: full path of a script

2007-09-24, 19:53(+02), Joachim Schmitz:
>
> "Miles" schrieb im Newsbeitrag
> news:1190646536.535556.17840@19g2000hsx.googlegroups.com...
>>> You'd need to check
>>> whether $0 starts with /, if so, everything is fine and you're done
>>> else if it starts with ., prepend $(PWD) and (optionally) find a way to
>>> normalize that (e.g.: cd $(dirname $(pwd)/$0;pwd)
>> I agree 100%.
>>
>>> else search $PATH until you find $0
>> No. There is no guarantee that the script is in your path.
> I think that a script, if not called with an absolute or relative pathname
> would be searched for in PATH, just like every other executable.
[...]

And $0 would then contain the full path to the script. It's only
when called as:

zsh some-script

and that some-script is not in the current directory, that $0
will contain "some-script" and that it won't be the path to the
file.

This subject has been discussed many times here.

prg=$0
[[ -x $prg || $prg = */* ]] || prg=$(whence -p -- $prg)
dir=$(cd -P -- $prg:h && pwd -P) || dir=$prg:h

":h", "[[", "whence" are not standard sh features.

--
Stéphane

Re: full path of a script

Miles schrieb:
> On Sep 24, 12:42 pm, Martin Krischik
> wrote:
>> Bill Marcum wrote:
>>> On Mon, 24 Sep 2007 15:11:51 +0200, Martin Krischik
>>> wrote:
>>>> Hello.
>>>> currently use the following code to get the full path of the currently
>>>> running script:
>>>> pushd "$(dirname ${0})";
>>>> typeset -r My_Dir=$(pwd);
>>>> popd;
>>>> But somehow I think there must be a better way. So is there?
>>>> Martin
>>> I think the better way in Unix is not to make your script depend on
>>> knowing its own location, but some ideas on this topic were discussed
>>> recently in this newsgroup.
>> There are additional support files in same directory. Now that alone would
>> not be a problem. The script also make a pushd into another place from
>> where it tries to access the named file.
>>
>> As said: I have a working solution. I was just wonder if there is a better
>> way. On windows I would use either %@FULL [1] or %@TRUENAME [2] and I am
>> kind of supprised that Unix has nothing in that direction.
>>
>> Martin
>>
>> [1]http://www.jpsoft.com/help/index.htm?f_full.htm
>> [2]http://www.jpsoft.com/help/index.htm?f_truename.htm
>>
>> --
>> mailto://krisc...@users.sourceforge.net
>> Ada programming at:http://ada.krischik.com
>
> I don't know if this works for everyone: our UNIX admin scripts are
> mainly in one directory. It happens to be /home/unxsa/bin - unx is
> UNIX and sa for System Administration. That doesn't really matter. So,
> I have an environment variable defined in /etc/profile:
>
> UNIX_SYSTEM_DIRECTORY=/home/unxsa
>
> I also define: SCRDIR=$UNIX_SYSTEM_DIRECTORY/bin
>
> Then if I ever need to know where the scripts are, I do.
>
> Is this just naive?

No not relay - only I am not wearing my an administrator hat but a
developers hat and the Script is not for production but development.
Your suggestion would mean 2 environment variables to be set by each
developer. And we already need approx. 3 days to get a developers
workstation up and running.

Any way: that's for all the suggestions. I learned something new :-) .

Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: full path of a script

"Stephane CHAZELAS" schrieb im Newsbeitrag
news:slrnffhacf.5a0.stephane.chazelas@spam.is.invalid...
> 2007-09-24, 19:53(+02), Joachim Schmitz:
>>
>> "Miles" schrieb im Newsbeitrag
>> news:1190646536.535556.17840@19g2000hsx.googlegroups.com...
>>>> You'd need to check
>>>> whether $0 starts with /, if so, everything is fine and you're done
>>>> else if it starts with ., prepend $(PWD) and (optionally) find a way to
>>>> normalize that (e.g.: cd $(dirname $(pwd)/$0;pwd)
>>> I agree 100%.
>>>
>>>> else search $PATH until you find $0
>>> No. There is no guarantee that the script is in your path.
>> I think that a script, if not called with an absolute or relative
>> pathname
>> would be searched for in PATH, just like every other executable.
> [...]
>
> And $0 would then contain the full path to the script.
> when called as:
Apparently not in ksh, there $0 expands to a relative path. If found in the
current directory (and that is part of PATH), it expands to the plain
basename ("file")
In bash it expands to an absolut path, unless it is in your current
directory (and that is part of PATH), in wich case it expands to a relative
path ("./file")

< It's only
> zsh some-script
>
> and that some-script is not in the current directory, that $0
> will contain "some-script" and that it won't be the path to the
> file.
>
> This subject has been discussed many times here.
>
> prg=$0
> [[ -x $prg || $prg = */* ]] || prg=$(whence -p -- $prg)
> dir=$(cd -P -- $prg:h && pwd -P) || dir=$prg:h
good stuff, thanks

> ":h", "[[", "whence" are not standard sh features.
:h could be substituted by
dir=$(cd -P -- ${prg%/*} && pwd -P) || dir=${prg%/*}

BTW: my pwd simply ignores -P, as does my cd (ksh builtin)

Bye, Jojo

Re: full path of a script

2007-09-25, 09:36(+02), Joachim Schmitz:
[...]
>>> I think that a script, if not called with an absolute or relative
>>> pathname
>>> would be searched for in PATH, just like every other executable.
>> [...]
>>
>> And $0 would then contain the full path to the script.
>> when called as:
> Apparently not in ksh, there $0 expands to a relative path. If found in the
> current directory (and that is part of PATH), it expands to the plain
> basename ("file")
> In bash it expands to an absolut path, unless it is in your current
> directory (and that is part of PATH), in wich case it expands to a relative
> path ("./file")

That surprises me. bash and ksh should output the same that is
your-script if $PATH contains "" or ./your-script if $PATH
contains ".".

~/bin$ print '#! /bin/bash -\nprintf "%s\\n" "$0"' > a
~/bin$ chmod +x a
~/bin$ PATH= /bin/bash -c a
a
~/bin$ PATH=. /bin/bash -c a
../a

Which version of bash are you using?

In the case above, $0 contains the path to the script which is
what I meant.

> < It's only
>> zsh some-script
>>
>> and that some-script is not in the current directory, that $0
>> will contain "some-script" and that it won't be the path to the
>> file.
>>
>> This subject has been discussed many times here.
>>
>> prg=$0
>> [[ -x $prg || $prg = */* ]] || prg=$(whence -p -- $prg)
>> dir=$(cd -P -- $prg:h && pwd -P) || dir=$prg:h
> good stuff, thanks
>
>> ":h", "[[", "whence" are not standard sh features.
> :h could be substituted by

Note that the OP was asking for a zsh solution, hence the use of
the zsh specific (comes from csh) :h

> dir=$(cd -P -- ${prg%/*} && pwd -P) || dir=${prg%/*}

Won't work if $prg contains no slash and you forgot some quotes.

dir=$(cd -P -- "$(dirname -- "$prg")" && pwd -P) || ...

>
> BTW: my pwd simply ignores -P, as does my cd (ksh builtin)
[...]

Nope, ksh's cd/pwd builtins use logical paths by default. You
*need* the -P here for cases where $prg contains some ".."
components.

Try doing a /tmp/my-script script, then a ln -s . /tmp/foo/testdir
cd /tmp/foo/testdir/testdir/testdir/testdir and run ../my-script
for instance.

--
Stéphane

Re: full path of a script

"Stephane CHAZELAS" schrieb im Newsbeitrag
news:slrnffhrh8.7pt.stephane.chazelas@spam.is.invalid...
> 2007-09-25, 09:36(+02), Joachim Schmitz:
> [...]
>>>> I think that a script, if not called with an absolute or relative
>>>> pathname
>>>> would be searched for in PATH, just like every other executable.
>>> [...]
>>>
>>> And $0 would then contain the full path to the script.
>>> when called as:
>> Apparently not in ksh, there $0 expands to a relative path. If found in
>> the
>> current directory (and that is part of PATH), it expands to the plain
>> basename ("file")
>> In bash it expands to an absolut path, unless it is in your current
>> directory (and that is part of PATH), in wich case it expands to a
>> relative
>> path ("./file")
>
> That surprises me. bash and ksh should output the same that is
> your-script if $PATH contains "" or ./your-script if $PATH
> contains ".".
> ~/bin$ print '#! /bin/bash -\nprintf "%s\\n" "$0"' > a
> ~/bin$ chmod +x a
> ~/bin$ PATH= /bin/bash -c a
> a
> ~/bin$ PATH=. /bin/bash -c a
> ./a
Here too... and no contradiction to what I said. Or meant to say... if bash
finds it somewhere in PATH, $0 contains an absolute pathname, if it is in
the current dir and that is part of PATH, it prints a relative name
ksh behaves different, here $0 expands to a relative path if it is found
somewhere in PATH and to a plain filename if it's found in the current
directory

> Which version of bash are you using?
3.1.0

> In the case above, $0 contains the path to the script which is
> what I meant.
>
>> < It's only
>>> zsh some-script
>>>
>>> and that some-script is not in the current directory, that $0
>>> will contain "some-script" and that it won't be the path to the
>>> file.
>>>
>>> This subject has been discussed many times here.
>>>
>>> prg=$0
>>> [[ -x $prg || $prg = */* ]] || prg=$(whence -p -- $prg)
>>> dir=$(cd -P -- $prg:h && pwd -P) || dir=$prg:h
>> good stuff, thanks
>>
>>> ":h", "[[", "whence" are not standard sh features.
>> :h could be substituted by
>
> Note that the OP was asking for a zsh solution, hence the use of
> the zsh specific (comes from csh) :h
fair enough.

>> dir=$(cd -P -- ${prg%/*} && pwd -P) || dir=${prg%/*}
>
> Won't work if $prg contains no slash and you forgot some quotes.
True and exactly the problem I have in ksh.

> dir=$(cd -P -- "$(dirname -- "$prg")" && pwd -P) || ...
>>
>> BTW: my pwd simply ignores -P, as does my cd (ksh builtin)
> [...]
>
> Nope, ksh's cd/pwd builtins use logical paths by default. You
> *need* the -P here for cases where $prg contains some ".."
> components.
You're right, I've looked it up in the source code, it's well hidden (and I
missed it the first time), but it's indeed there... It doesn't seem
documented though

> Try doing a /tmp/my-script script, then a ln -s . /tmp/foo/testdir
> cd /tmp/foo/testdir/testdir/testdir/testdir and run ../my-script
> for instance.


Bye, Jojo

Re: full path of a script

2007-09-25, 15:01(+02), Joachim Schmitz:
[...]
>> ~/bin$ print '#! /bin/bash -\nprintf "%s\\n" "$0"' > a
>> ~/bin$ chmod +x a
>> ~/bin$ PATH= /bin/bash -c a
>> a
>> ~/bin$ PATH=. /bin/bash -c a
>> ./a
> Here too... and no contradiction to what I said. Or meant to say... if bash
> finds it somewhere in PATH, $0 contains an absolute pathname

First both (except for some old bogus versions of ksh) only
lookup the command in $PATH if the script name passed as
argument doesn't contain any slash and is not to be found in the
current directory. That's why I said it can only happen if you
call the shell interpreter directly as in "bash a" or "ksh a".

In that case, I find that both bash and ksh behave the same:

~$ PATH=~/bin /bin/ksh a
a
~$ PATH=~/bin /bin/bash a
a

>, if it is in
> the current dir and that is part of PATH, it prints a relative name
> ksh behaves different, here $0 expands to a relative path if it is found
> somewhere in PATH and to a plain filename if it's found in the current
> directory
[...]

I still don't see what you mean. I know some old versions of ksh
had a bug where it would search in $PATH before searching in the
current directory. Is that what you are refering to?

If not, could you please give an example?

[...]
> You're right, I've looked it up in the source code, it's well hidden (and I
> missed it the first time), but it's indeed there... It doesn't seem
> documented though
[...]

I beleive it is. And it's also how it is specified by POSIX, cd
is a short for "cd -L", same for pwd. In scripts using -L almost
never makes sense, so systematically adding -P is generally a
good idea.


--
Stéphane

Re: full path of a script

"Stephane CHAZELAS" schrieb im Newsbeitrag
news:slrnffi2hb.8o7.stephane.chazelas@spam.is.invalid...
> 2007-09-25, 15:01(+02), Joachim Schmitz:
> [...]
>>> ~/bin$ print '#! /bin/bash -\nprintf "%s\\n" "$0"' > a
>>> ~/bin$ chmod +x a
>>> ~/bin$ PATH= /bin/bash -c a
>>> a
>>> ~/bin$ PATH=. /bin/bash -c a
>>> ./a
>> Here too... and no contradiction to what I said. Or meant to say... if
>> bash
>> finds it somewhere in PATH, $0 contains an absolute pathname
>
> First both (except for some old bogus versions of ksh) only
> lookup the command in $PATH if the script name passed as
> argument doesn't contain any slash and is not to be found in the
> current directory. That's why I said it can only happen if you
> call the shell interpreter directly as in "bash a" or "ksh a".
>
> In that case, I find that both bash and ksh behave the same:
>
> ~$ PATH=~/bin /bin/ksh a
> a
> ~$ PATH=~/bin /bin/bash a
> a
>
>>, if it is in
>> the current dir and that is part of PATH, it prints a relative name
>> ksh behaves different, here $0 expands to a relative path if it is found
>> somewhere in PATH and to a plain filename if it's found in the current
>> directory
> [...]
>
> I still don't see what you mean. I know some old versions of ksh
> had a bug where it would search in $PATH before searching in the
> current directory. Is that what you are refering to?
No, don't think so, but see below.

> If not, could you please give an example?
First with bash:
jojo@\rat0:~ $ ps
PID TTY TIME CMD
1039728713 ptk69dr 00:00 ps
100204598 ptk69dr 00:00 -bash
jojo@\rat0:~ $ export PATH=/bin:~/bin:.
jojo@\rat0:~ $ a
../a
jojo@\rat0:~ $ mv a bin
jojo@\rat0:~ $ a
/home/jojo/bin/a

Now with ksh:
jojo@\rat:/home/jojo $ ps
PID TTY TIME CMD
284753983 ptk69ds 00:00 ps
116981833 ptk69ds 00:00 -ksh
jojo@\rat0:~ $ export PATH=/bin:~/bin:.
jojo@\rat0:~ $ a
bin/a
jojo@\rat0:~ $ mv bin/a .
jojo@\rat0:~ $ a
a
jojo@\rat0:~ $ cp a bin
jojo@\rat0:~ $ a
bin/a

> [...]
>> You're right, I've looked it up in the source code, it's well hidden (and
>> I
>> missed it the first time), but it's indeed there... It doesn't seem
>> documented though
> [...]
>
> I beleive it is. And it's also how it is specified by POSIX, cd
> is a short for "cd -L", same for pwd. In scripts using -L almost
> never makes sense, so systematically adding -P is generally a
> good idea.
It is not documented here on my system, neither in the man-page for ksh not
in those for pwd or cd. Might well be a bug...
If I 'cd' to a symlink, a 'pwd -P' produces different output from a 'pwd -L'
(or a plain 'pwd'), so the functionality is there, and I've learned
something new today 8-)

Bye, Jojo

Re: full path of a script

Martin Krischik wrote:
> ... get the full path of the currently running script ....

Oddly enough, I provided what I think is the definitive solution just
one week ago. See my resolvepath script through the page:

http://groups.google.com/group/comp.unix.shell/browse_thread /thread/a7a0bc41d6e57f85/9d5d24323ceb7aca?lnk=st&q=&rnum=4#9 d5d24323ceb7aca

> pushd "$(dirname ${0})";
> typeset -r My_Dir=$(pwd);
> popd;

It's important not to use terminating semicolons in scripts. Although
usually benign (and a boon to a beautifier program that you may or may
not be using), they have a fundamentally different syntactic function
that
their use in the usual compiled languages. See:

http://groups.google.com/group/comp.unix.shell/browse_thread /thread/8007e80721a277aa/27ed00e545a0a292?lnk=st&q=&rnum=7#2 7ed00e545a0a292

Interesting usage, BTW.

P.S. According to your Google Profile, we are identical twins; can I
use
your photo for my profile as well? ;) ;)

=Brian

Re: full path of a script

2007-09-25, 16:38(+02), Joachim Schmitz:
[...]
>>>> ~/bin$ print '#! /bin/bash -\nprintf "%s\\n" "$0"' > a
[...]
> First with bash:
> jojo@\rat0:~ $ ps
> PID TTY TIME CMD
> 1039728713 ptk69dr 00:00 ps
> 100204598 ptk69dr 00:00 -bash
> jojo@\rat0:~ $ export PATH=/bin:~/bin:.
> jojo@\rat0:~ $ a
> ./a
> jojo@\rat0:~ $ mv a bin
> jojo@\rat0:~ $ a
> /home/jojo/bin/a
>
> Now with ksh:
> jojo@\rat:/home/jojo $ ps
> PID TTY TIME CMD
> 284753983 ptk69ds 00:00 ps
> 116981833 ptk69ds 00:00 -ksh
> jojo@\rat0:~ $ export PATH=/bin:~/bin:.
> jojo@\rat0:~ $ a
> bin/a
> jojo@\rat0:~ $ mv bin/a .
> jojo@\rat0:~ $ a
> a
> jojo@\rat0:~ $ cp a bin
> jojo@\rat0:~ $ a
> bin/a
[...]

That doesn't make sense to me. Why would ksh do such a think as
making a relative directory out of an absolute one.

If you run it from ~/tmp, so you see ../bin/a?

I can't reproduce the above with any of pdksh, ksh93s nor
Solaris' ksh, which version of ksh are you using?


--
Stéphane

Re: full path of a script

2007-09-25, 16:52(-07), bsh:
> Martin Krischik wrote:
>> ... get the full path of the currently running script ....
>
> Oddly enough, I provided what I think is the definitive solution just
> one week ago. See my resolvepath script through the page:
[...]

Brian,

in your script, you say:

# Ksh Bug: "cd -P dir" works, but "cd -P -- dir" does not!

do you know which version of ksh is affected by that bug?

I could not reproduce it with any of ksh88i on Solaris, ksh93s+
on Linux, pkdsh, posh, mksh, zsh's ksh or even the very old
ksh88 on HPUX. And that would make it not POSIX conformant.

Or maybe could you clarify in which way it doesn't work?

--
Stéphane

Re: full path of a script

Stephane CHAZELAS wrote:
> bsh wrote:
> > Martin Krischik wrote:
> > > ...
> # Ksh Bug: "cd -P dir" works, but "cd -P -- dir" does not!

> do you know which version of ksh is affected by that bug?

It is a bit of time since I've revisioned or even used resolvepath,
but my recollection is that I saw this behavior under ksh88d,
which I compiled from C source to use on my SunOS4.1.1,
at the time when was no kornshell for that OS. Perhaps Sven
Maschek knows the applicable revision? He keeps (and
reads!) the changelogs.

> I could not reproduce it with any of ksh88i on Solaris, ksh93s+
> on Linux, pkdsh, posh, mksh, zsh's ksh or even the very old
> ksh88 on HPUX. And that would make it not POSIX conformant.

I am pleased that this issue has finally been resolved.
Presumably it was originally a ramification of Korn's
statement in "The KornShell Command and
Programming Language" (the 1st edition covering only
ksh88) that (IIRC) "cd" and other builtin, like the original
"echo", specifically took no option arguments. This
obviously was problematic once cd _did_ take option
arguments. This reminds me of the early debacle that
ensued when scripts were run that assumed the old
behavior of the "cd" builtin errorexiting the script when the
directory did not exist or could not be chdir'ed to. Chaos!

> Or maybe could you clarify in which way it doesn't work?

I guess that DGK coded an kludge that used an ad hoc
option parsing function that assumed one and only one
option argument, instead of properly using getopts(3),
which understands the special option "--". Otherwise,
the behavior I observed was that the chdir was looking
for a file/directory named "--".

P.S. Since you have all these shells available for testing
(wish I did!), and have expressed a preferance for using
zsh(1), are you aware of an IEEE 754 arithmetic enhancement
specifically for this shell at:

http://www.math.utah.edu/pub/zsh/README.NONSTOP-FP

=Brian

Re: full path of a script

"Stephane CHAZELAS" schrieb im Newsbeitrag
news:slrnffllqt.cum.stephane.chazelas@spam.is.invalid...
> 2007-09-25, 16:38(+02), Joachim Schmitz:
> [...]
>>>>> ~/bin$ print '#! /bin/bash -\nprintf "%s\\n" "$0"' > a
> [...]
>> First with bash:
>> jojo@\rat0:~ $ ps
>> PID TTY TIME CMD
>> 1039728713 ptk69dr 00:00 ps
>> 100204598 ptk69dr 00:00 -bash
>> jojo@\rat0:~ $ export PATH=/bin:~/bin:.
>> jojo@\rat0:~ $ a
>> ./a
>> jojo@\rat0:~ $ mv a bin
>> jojo@\rat0:~ $ a
>> /home/jojo/bin/a
>>
>> Now with ksh:
>> jojo@\rat:/home/jojo $ ps
>> PID TTY TIME CMD
>> 284753983 ptk69ds 00:00 ps
>> 116981833 ptk69ds 00:00 -ksh
>> jojo@\rat0:~ $ export PATH=/bin:~/bin:.
>> jojo@\rat0:~ $ a
>> bin/a
>> jojo@\rat0:~ $ mv bin/a .
>> jojo@\rat0:~ $ a
>> a
>> jojo@\rat0:~ $ cp a bin
>> jojo@\rat0:~ $ a
>> bin/a
> [...]
>
> That doesn't make sense to me. Why would ksh do such a think as
> making a relative directory out of an absolute one.
Does it? Ah, yes, the ~ in PATH expands to an absolute pathname
("/home/jojo")

> If you run it from ~/tmp, so you see ../bin/a?
No, I see a "tmp/a"
tmp/a being a symlink to bin/a and called as ~/tmp/a, so indeed it does
truncates the absolute path.
Pretty bizarre...

> I can't reproduce the above with any of pdksh, ksh93s nor
> Solaris' ksh, which version of ksh are you using?
Not sure, from looking at the source it's derived from OSF/1 1.2.
I know for sure that we added a couple of things to it.

Bye, Jojo

Re: full path of a script

bsh wrote:
> Stephane CHAZELAS wrote:
>> bsh wrote:

>> # Ksh Bug: "cd -P dir" works, but "cd -P -- dir" does not!
>
>> do you know which version of ksh is affected by that bug?
>> I could not reproduce it with any of ksh88i on Solaris, ksh93s+
>
> [...] my recollection is that I saw this behavior under ksh88d,

I guess, there are several issues here.
But one is just to end the options:

$ mkdir ./-a
$ cd -P -- -a ; cd -- -a

At least ksh88-d and -i don't know "--" and fail with "cd: bad option(s)".