Hi all,
we are glad to announce BaseX 7.0.1, which is basically the result of your initial feedback on 7.0. Those are the most important changes:
DISTRIBUTIONS: - Windows installer was updated to support latest features - ZIP file was updated (initial config & directories added) - Short directory names are chosen if config file resides in app.dir. - Start scripts have been improved
XQUERY: - much faster execution of count() when applied to opened databases
SERVER (http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server): - Flag -c connects to an existing database server - Flag -s specifies a port for stopping the HTTP server (Jetty) - Flag -S starts the HTTP server as a service - running write operations will be completed before server is stopped
API: - Ruby, Python, PHP, Java: clients updated
Please check out the well-known links:
- Homepage: http://basex.org/ - Documentation: http://docs.basex.org/ - Snapshots: http://files.basex.org/releases/latest/ - Sources: https://github.com/BaseXdb
Enjoy the update!
Christian BaseX Team
Hi,
thanks a lot for this, the recent optimizations are really appreciated :D
Just one minor nitpick is left, from my side... if I create a symlink to one of the scripts in bin/, it stops to work. This is caused by the script looking for its class files in the folder the script is in, without taking symlinks into account. It can be fixed by replacing the PWD= line in each script with the following PWD="$(dirname "$(readlink -e "$0")")"
However, the -e option of readlink is a GNU extension, so non-Linux UNIXes (most notably Mac OS) will probably not support that option. If you want to support those OSes, it gets a bit more complicated, one could do something like this (which I did not test):
if readlink -e . &> /dev/null; then # readlink supports -e, use it PWD="$(dirname "$(readlink -e "$0")")" else # readlink does not support -e (e.g. Mac OS) # do not support being called through symlinks PWD="$(dirname "$0")" fi
With some shell magic it might also be possible to follow symlinks on Mac, but honestly I don't care enough about Mac to look into that ;-) . This keeps the status quo on Mac (and others), and makes things better on Linux.
Kind regards, Ralf
On Sunday 23 October 2011 21:48:03 Christian Grün wrote:
Hi all,
we are glad to announce BaseX 7.0.1, which is basically the result of your initial feedback on 7.0. Those are the most important changes:
DISTRIBUTIONS:
- Windows installer was updated to support latest features
- ZIP file was updated (initial config & directories added)
- Short directory names are chosen if config file resides in app.dir.
- Start scripts have been improved
XQUERY:
- much faster execution of count() when applied to opened databases
SERVER (http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server):
- Flag -c connects to an existing database server
- Flag -s specifies a port for stopping the HTTP server (Jetty)
- Flag -S starts the HTTP server as a service
- running write operations will be completed before server is stopped
API:
- Ruby, Python, PHP, Java: clients updated
Please check out the well-known links:
- Homepage: http://basex.org/
- Documentation: http://docs.basex.org/
- Snapshots: http://files.basex.org/releases/latest/
- Sources: https://github.com/BaseXdb
Enjoy the update!
Christian BaseX Team _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Ralf, thanks for the proposal - nitpicks are welcome as well ;) Before applying the changes, I'd like to have some feedback from Mac users, though.. Did someone try the alternative script?
Christian ___________________________
On Mon, Oct 24, 2011 at 8:06 PM, Ralf Jung ralfjung-e@gmx.de wrote:
Hi,
thanks a lot for this, the recent optimizations are really appreciated :D
Just one minor nitpick is left, from my side... if I create a symlink to one of the scripts in bin/, it stops to work. This is caused by the script looking for its class files in the folder the script is in, without taking symlinks into account. It can be fixed by replacing the PWD= line in each script with the following PWD="$(dirname "$(readlink -e "$0")")"
However, the -e option of readlink is a GNU extension, so non-Linux UNIXes (most notably Mac OS) will probably not support that option. If you want to support those OSes, it gets a bit more complicated, one could do something like this (which I did not test):
if readlink -e . &> /dev/null; then # readlink supports -e, use it PWD="$(dirname "$(readlink -e "$0")")" else # readlink does not support -e (e.g. Mac OS) # do not support being called through symlinks PWD="$(dirname "$0")" fi
With some shell magic it might also be possible to follow symlinks on Mac, but honestly I don't care enough about Mac to look into that ;-) . This keeps the status quo on Mac (and others), and makes things better on Linux.
Kind regards, Ralf
On Sunday 23 October 2011 21:48:03 Christian Grün wrote:
Hi all,
we are glad to announce BaseX 7.0.1, which is basically the result of your initial feedback on 7.0. Those are the most important changes:
DISTRIBUTIONS:
- Windows installer was updated to support latest features
- ZIP file was updated (initial config & directories added)
- Short directory names are chosen if config file resides in app.dir.
- Start scripts have been improved
XQUERY:
- much faster execution of count() when applied to opened databases
SERVER (http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server):
- Flag -c connects to an existing database server
- Flag -s specifies a port for stopping the HTTP server (Jetty)
- Flag -S starts the HTTP server as a service
- running write operations will be completed before server is stopped
API:
- Ruby, Python, PHP, Java: clients updated
Please check out the well-known links:
- Homepage: http://basex.org/
- Documentation: http://docs.basex.org/
- Snapshots: http://files.basex.org/releases/latest/
- Sources: https://github.com/BaseXdb
Enjoy the update!
Christian BaseX Team _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Christian and Ralf,
was building around `readlink -e` myself until I found out somebody on [stackoverflow][1] actually had the same problem and some working solution, too. (Found it after I realized having problems with pwd not resolving symlinks in folders - had written essentially the same code apart from whitespace and variable naming…)
Just put the script somewhere in BaseX' scripts folder and replace `readlink -e` by this script. Completely based on POSIX commands and options, so should work on all UNIXes.
#!/bin/sh
TARGET_FILE=$1
cd `dirname $TARGET_FILE` TARGET_FILE=`basename $TARGET_FILE`
# Iterate down a (possible) chain of symlinks while [ -L "$TARGET_FILE" ] do TARGET_FILE=`readlink $TARGET_FILE` cd `dirname $TARGET_FILE` TARGET_FILE=`basename $TARGET_FILE` done
# Compute the canonicalized name by finding the physical path # for the directory we're in and appending the target file. PHYS_DIR=`pwd -P` RESULT=$PHYS_DIR/$TARGET_FILE echo $RESULT
Kind regards, Jens
[1]:http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnu...
Hi,
was building around `readlink -e` myself until I found out somebody on [stackoverflow][1] actually had the same problem and some working solution, too. (Found it after I realized having problems with pwd not resolving symlinks in folders - had written essentially the same code apart from whitespace and variable naming…)
Just put the script somewhere in BaseX' scripts folder and replace `readlink -e` by this script. Completely based on POSIX commands and options, so should work on all UNIXes.
That will not work, how can the start scripts find the BaseX folder to source the path-resolution script? The whole code needs to be copied into each start script.
Kind regards, Ralf
Hi Jens, hi Ralf,
Just put the script somewhere in BaseX' scripts folder and replace `readlink -e` by this script. Completely based on POSIX commands and options, so should work on all UNIXes.
I'm feeling clumsy.. How will the script file be found by the main script if the absolute path has not been evaluated yet?
Christian ___________________________
On Tue, Oct 25, 2011 at 3:53 PM, Jens Erat jens.erat@uni-konstanz.de wrote:
Hi Christian and Ralf,
was building around `readlink -e` myself until I found out somebody on [stackoverflow][1] actually had the same problem and some working solution, too. (Found it after I realized having problems with pwd not resolving symlinks in folders - had written essentially the same code apart from whitespace and variable naming…)
#!/bin/sh
TARGET_FILE=$1
cd `dirname $TARGET_FILE` TARGET_FILE=`basename $TARGET_FILE`
# Iterate down a (possible) chain of symlinks while [ -L "$TARGET_FILE" ] do TARGET_FILE=`readlink $TARGET_FILE` cd `dirname $TARGET_FILE` TARGET_FILE=`basename $TARGET_FILE` done
# Compute the canonicalized name by finding the physical path # for the directory we're in and appending the target file. PHYS_DIR=`pwd -P` RESULT=$PHYS_DIR/$TARGET_FILE echo $RESULT
Kind regards, Jens
-- Jens Erat
[phone]: tel:+49-151-56961126 [mail]: mailto:email@jenserat.de [jabber]: xmpp:jabber@jenserat.de [web]: http://www.jenserat.de
PGP: 350E D9B6 9ADC 2DED F5F2 8549 CBC2 613C D745 722B
Am 25.10.2011 um 14:44 schrieb Christian Grün:
Ralf, thanks for the proposal - nitpicks are welcome as well ;) Before applying the changes, I'd like to have some feedback from Mac users, though.. Did someone try the alternative script?
Christian ___________________________
On Mon, Oct 24, 2011 at 8:06 PM, Ralf Jung ralfjung-e@gmx.de wrote:
Hi,
thanks a lot for this, the recent optimizations are really appreciated :D
Just one minor nitpick is left, from my side... if I create a symlink to one of the scripts in bin/, it stops to work. This is caused by the script looking for its class files in the folder the script is in, without taking symlinks into account. It can be fixed by replacing the PWD= line in each script with the following PWD="$(dirname "$(readlink -e "$0")")"
However, the -e option of readlink is a GNU extension, so non-Linux UNIXes (most notably Mac OS) will probably not support that option. If you want to support those OSes, it gets a bit more complicated, one could do something like this (which I did not test):
if readlink -e . &> /dev/null; then # readlink supports -e, use it PWD="$(dirname "$(readlink -e "$0")")" else # readlink does not support -e (e.g. Mac OS) # do not support being called through symlinks PWD="$(dirname "$0")" fi
With some shell magic it might also be possible to follow symlinks on Mac, but honestly I don't care enough about Mac to look into that ;-) . This keeps the status quo on Mac (and others), and makes things better on Linux.
Kind regards, Ralf
On Sunday 23 October 2011 21:48:03 Christian Grün wrote:
Hi all,
we are glad to announce BaseX 7.0.1, which is basically the result of your initial feedback on 7.0. Those are the most important changes:
DISTRIBUTIONS:
- Windows installer was updated to support latest features
- ZIP file was updated (initial config & directories added)
- Short directory names are chosen if config file resides in app.dir.
- Start scripts have been improved
XQUERY:
- much faster execution of count() when applied to opened databases
SERVER (http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server):
- Flag -c connects to an existing database server
- Flag -s specifies a port for stopping the HTTP server (Jetty)
- Flag -S starts the HTTP server as a service
- running write operations will be completed before server is stopped
API:
- Ruby, Python, PHP, Java: clients updated
Please check out the well-known links:
- Homepage: http://basex.org/
- Documentation: http://docs.basex.org/
- Snapshots: http://files.basex.org/releases/latest/
- Sources: https://github.com/BaseXdb
Enjoy the update!
Christian BaseX Team _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJOpr9cAAoJENqoVWI6Xmj3ToEIAK2IVsRobanZSfPB1qpxoLai 0TY0DUOqz2IdVrsh/VlMSs/UT12cc4WbghEMKkBuQBrnOXi7MoHKc4lVzKIHWasb +TH2Xg9sUY76xeZ2Z5ouhAJcAMULgp00pp9FHGEAqCXxLvwPNMLfNWunpP2i8HN/ 6ITFLxci3bDC45x59R/aTbeqOeNO38spJKpnAg4cSOj4qyK7k9TH/kqz+B007VO/ H2LGQI+9uEKV7edhBozrzJGl+LDZDgubgPaylRdeSc6jA4fn+YrDWlE2DagOwWqM 5exsTL1Wv77XvrdxZvItrQULOXyuUrOb8oEmI1DM1ETqMA4wWjWg3PWYsv/J0ko= =GIId -----END PGP SIGNATURE-----
Am 03.11.2011 um 22:42 schrieb Christian Grün:
Hi Jens, hi Ralf,
Just put the script somewhere in BaseX' scripts folder and replace `readlink -e` by this script. Completely based on POSIX commands and options, so should work on all UNIXes.
I'm feeling clumsy.. How will the script file be found by the main script if the absolute path has not been evaluated yet?
I guess the readlink mimic script should be residing inside $PATH anyway? But I'd rather not bloat $PATH with yet another script and instead put that logic in every script that needs it, not too elegant, I admit.
Michael
Hi Christian,
that's what I already replied to Jens and the list - naturally, any script that finds the script path must be emdedded into all startup scripts. Which for this script means that it has to be executed in a subshell since it changes the pwd... there was some shell syntax to do that, but I do not remember it currently.
Kind regards, Ralf
On Thursday 03 November 2011 22:42:34 Christian Grün wrote:
Hi Jens, hi Ralf,
Just put the script somewhere in BaseX' scripts folder and replace `readlink -e` by this script. Completely based on POSIX commands and options, so should work on all UNIXes.
I'm feeling clumsy.. How will the script file be found by the main script if the absolute path has not been evaluated yet?
Christian ___________________________
On Tue, Oct 25, 2011 at 3:53 PM, Jens Erat jens.erat@uni-konstanz.de
wrote:
Hi Christian and Ralf,
was building around `readlink -e` myself until I found out somebody on [stackoverflow][1] actually had the same problem and some working solution, too. (Found it after I realized having problems with pwd not resolving symlinks in folders - had written essentially the same code apart from whitespace and variable naming…)
#!/bin/sh
TARGET_FILE=$1
cd `dirname $TARGET_FILE` TARGET_FILE=`basename $TARGET_FILE`
# Iterate down a (possible) chain of symlinks while [ -L "$TARGET_FILE" ] do TARGET_FILE=`readlink $TARGET_FILE` cd `dirname $TARGET_FILE` TARGET_FILE=`basename $TARGET_FILE` done
# Compute the canonicalized name by finding the physical path # for the directory we're in and appending the target file. PHYS_DIR=`pwd -P` RESULT=$PHYS_DIR/$TARGET_FILE echo $RESULT
Kind regards, Jens
-of-gnus-readlink-f-on-a-mac/1116890#1116890
-- Jens Erat
PGP: 350E D9B6 9ADC 2DED F5F2 8549 CBC2 613C D745 722BAm 25.10.2011 um 14:44 schrieb Christian Grün:
Ralf, thanks for the proposal - nitpicks are welcome as well ;) Before applying the changes, I'd like to have some feedback from Mac users, though.. Did someone try the alternative script?
Christian ___________________________
On Mon, Oct 24, 2011 at 8:06 PM, Ralf Jung ralfjung-e@gmx.de wrote:
Hi,
thanks a lot for this, the recent optimizations are really appreciated :D
Just one minor nitpick is left, from my side... if I create a symlink to one of the scripts in bin/, it stops to work. This is caused by the script looking for its class files in the folder the script is in, without taking symlinks into account. It can be fixed by replacing the PWD= line in each script with the following PWD="$(dirname "$(readlink -e "$0")")"
However, the -e option of readlink is a GNU extension, so non-Linux UNIXes (most notably Mac OS) will probably not support that option. If you want to support those OSes, it gets a bit more complicated, one could do something like this (which I did not test):
if readlink -e . &> /dev/null; then # readlink supports -e, use it PWD="$(dirname "$(readlink -e "$0")")" else # readlink does not support -e (e.g. Mac OS) # do not support being called through symlinks PWD="$(dirname "$0")" fi
With some shell magic it might also be possible to follow symlinks on Mac, but honestly I don't care enough about Mac to look into that ;-) . This keeps the status quo on Mac (and others), and makes things better on Linux.
Kind regards, Ralf
On Sunday 23 October 2011 21:48:03 Christian Grün wrote:
Hi all,
we are glad to announce BaseX 7.0.1, which is basically the result of your initial feedback on 7.0. Those are the most important changes:
DISTRIBUTIONS:
- Windows installer was updated to support latest features
- ZIP file was updated (initial config & directories added)
- Short directory names are chosen if config file resides in app.dir.
- Start scripts have been improved
XQUERY:
- much faster execution of count() when applied to opened databases
SERVER (http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server):
- Flag -c connects to an existing database server
- Flag -s specifies a port for stopping the HTTP server (Jetty)
- Flag -S starts the HTTP server as a service
- running write operations will be completed before server is stopped
API:
- Ruby, Python, PHP, Java: clients updated
Please check out the well-known links:
- Homepage: http://basex.org/
- Documentation: http://docs.basex.org/
- Snapshots: http://files.basex.org/releases/latest/
- Sources: https://github.com/BaseXdb
Enjoy the update!
Christian BaseX Team _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJOpr9cAAoJENqoVWI6Xmj3ToEIAK2IVsRobanZSfPB1qpxoLai 0TY0DUOqz2IdVrsh/VlMSs/UT12cc4WbghEMKkBuQBrnOXi7MoHKc4lVzKIHWasb +TH2Xg9sUY76xeZ2Z5ouhAJcAMULgp00pp9FHGEAqCXxLvwPNMLfNWunpP2i8HN/ 6ITFLxci3bDC45x59R/aTbeqOeNO38spJKpnAg4cSOj4qyK7k9TH/kqz+B007VO/ H2LGQI+9uEKV7edhBozrzJGl+LDZDgubgPaylRdeSc6jA4fn+YrDWlE2DagOwWqM 5exsTL1Wv77XvrdxZvItrQULOXyuUrOb8oEmI1DM1ETqMA4wWjWg3PWYsv/J0ko= =GIId -----END PGP SIGNATURE-----
Am Freitag, 4. November 2011, 16:48:10 schrieb Ralf Jung:
there was some shell syntax to do that, but I do not remember it currently.
Again the holy StackOverflow with the help of it's helper St. Google:
http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what- directory-its-stored-in
Cheers, Dimitar
Unfortunately all solutions proposed there have problems with relative symlinks, which readlink does not resolve to absolute paths... (I have a symlink in ~/bin called basexhttp pointing to "basex/bin/basexhttp", but it tries to resolve the relative path from the directory I am in, instead of ~/bin)
The shortest one I could come up with that works for me and does not use readlink -e is based on http://stackoverflow.com/questions/1055671/how-can-i- get-the-behavior-of-gnus-readlink-f-on-a-mac
# find Path to this script pushd . > /dev/null SCRIPT_FILE="${BASH_SOURCE[0]}" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" # we need to get rid of the path part since we cd'ed # Iterate down a (possible) chain of symlinks while [ -L "$SCRIPT_FILE" ] do SCRIPT_FILE="$(readlink "$SCRIPT_FILE")" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" done # now we are in the directory we are looking for SCRIPT_DIR="$(pwd -P)" popd > /dev/null
Kind regards, Ralf
On Friday 04 November 2011 23:15:44 Dimitar Popov wrote:
Am Freitag, 4. November 2011, 16:48:10 schrieb Ralf Jung:
there was some shell syntax to do that, but I do not remember it currently.
Again the holy StackOverflow with the help of it's helper St. Google:
http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what- directory-its-stored-in
Cheers, Dimitar
Am Freitag, 4. November 2011, 23:31:27 schrieb Ralf Jung:
Unfortunately all solutions proposed there have problems with relative symlinks, which readlink does not resolve to absolute paths... (I have a symlink in ~/bin called basexhttp pointing to "basex/bin/basexhttp", but it tries to resolve the relative path from the directory I am in, instead of ~/bin)
The shortest one I could come up with that works for me and does not use readlink -e is based on http://stackoverflow.com/questions/1055671/how-can-i- get-the-behavior-of-gnus-readlink-f-on-a-mac
# find Path to this script pushd . > /dev/null SCRIPT_FILE="${BASH_SOURCE[0]}" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" # we need to get rid of the path part since we cd'ed # Iterate down a (possible) chain of symlinks while [ -L "$SCRIPT_FILE" ] do SCRIPT_FILE="$(readlink "$SCRIPT_FILE")" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" done # now we are in the directory we are looking for SCRIPT_DIR="$(pwd -P)" popd > /dev/null
What's wrong with simply using
SOURCE="${BASH_SOURCE[0]}" while [ -h "$SOURCE" ] ; do SOURCE="$(readlink "$SOURCE")"; done PWD="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
? It works on my computer, but I'm not Bash profi, so I might be missing something...
Greetings, Dimitar
Am Freitag, 4. November 2011, 23:41:31 schrieb Dimitar Popov:
Am Freitag, 4. November 2011, 23:31:27 schrieb Ralf Jung:
Unfortunately all solutions proposed there have problems with relative symlinks, which readlink does not resolve to absolute paths... (I have a symlink in ~/bin called basexhttp pointing to "basex/bin/basexhttp", but it tries to resolve the relative path from the directory I am in, instead of ~/bin)
The shortest one I could come up with that works for me and does not use readlink -e is based on http://stackoverflow.com/questions/1055671/how-can-i- get-the-behavior-of-gnus-readlink-f-on-a-mac
# find Path to this script pushd . > /dev/null SCRIPT_FILE="${BASH_SOURCE[0]}" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" # we need to get rid of the path part since we cd'ed # Iterate down a (possible) chain of symlinks while [ -L "$SCRIPT_FILE" ] do
SCRIPT_FILE="$(readlink "$SCRIPT_FILE")" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")"done # now we are in the directory we are looking for SCRIPT_DIR="$(pwd -P)" popd > /dev/null
What's wrong with simply using
SOURCE="${BASH_SOURCE[0]}" while [ -h "$SOURCE" ] ; do SOURCE="$(readlink "$SOURCE")"; done PWD="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
? It works on my computer, but I'm not Bash profi, so I might be missing something...
Ah, ok... I understand... "relative" is the keyword ;) It's getting late...
Greetings, Dimitar
Hi Ralf,
I modified your script a little, and came with the following shorter solution:
FILE="${BASH_SOURCE[0]}" while [ -h "$FILE" ] ; do SOURCE="$(readlink "$FILE")" FILE="$(dirname "$FILE")/$(dirname "$SOURCE")/$(basename "$SOURCE")" done BASEX_DIR="$( cd -P "$(dirname $FILE)" && pwd )"
Could you give it a try and tell me if you see any problems with it?
Many thanks in advance!
Dimitar
Am Freitag, 4. November 2011, 23:31:27 schrieb Ralf Jung:
Unfortunately all solutions proposed there have problems with relative symlinks, which readlink does not resolve to absolute paths... (I have a symlink in ~/bin called basexhttp pointing to "basex/bin/basexhttp", but it tries to resolve the relative path from the directory I am in, instead of ~/bin)
The shortest one I could come up with that works for me and does not use readlink -e is based on http://stackoverflow.com/questions/1055671/how-can-i- get-the-behavior-of-gnus-readlink-f-on-a-mac
# find Path to this script pushd . > /dev/null SCRIPT_FILE="${BASH_SOURCE[0]}" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" # we need to get rid of the path part since we cd'ed # Iterate down a (possible) chain of symlinks while [ -L "$SCRIPT_FILE" ] do SCRIPT_FILE="$(readlink "$SCRIPT_FILE")" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" done # now we are in the directory we are looking for SCRIPT_DIR="$(pwd -P)" popd > /dev/null
Kind regards, Ralf
On Friday 04 November 2011 23:15:44 Dimitar Popov wrote:
Am Freitag, 4. November 2011, 16:48:10 schrieb Ralf Jung:
there was some shell syntax to do that, but I do not remember it currently.
Again the holy StackOverflow with the help of it's helper St. Google:
http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what- directory-its-stored-in
Cheers, Dimitar
Am Sonntag, 6. November 2011, 21:22:57 schrieb Dimitar Popov:
Hi Ralf,
I modified your script a little, and came with the following shorter solution:
FILE="${BASH_SOURCE[0]}" while [ -h "$FILE" ] ; do SOURCE="$(readlink "$FILE")" FILE="$(dirname "$FILE")/$(dirname "$SOURCE")/$(basename "$SOURCE")" done BASEX_DIR="$( cd -P "$(dirname $FILE)" && pwd )"
Could you give it a try and tell me if you see any problems with it?
Many thanks in advance!
Dimitar
Forget it... it doesn't work correctly.
Dimitar
(resent with correct recipien ts)
Hi,
this will break if the link is absolute, since it will still prepend the $(dirname "$FILE") to the value we got from readlink. So if I call /home/r/bin/basexhttp, which is a link to /home/r/bin/basex/bin/basexhttp, it will set FILE to /home/r/bin//home/r/bin/basex/bin/basexhttp. Also, I wonder why you are splitting $SOURCE into basename and dirname, just to concat it again?
Kind regards, Ralf
On Sunday 06 November 2011 21:22:57 you wrote:
Hi Ralf,
I modified your script a little, and came with the following shorter solution:
FILE="${BASH_SOURCE[0]}" while [ -h "$FILE" ] ; do SOURCE="$(readlink "$FILE")" FILE="$(dirname "$FILE")/$(dirname "$SOURCE")/$(basename "$SOURCE")" done BASEX_DIR="$( cd -P "$(dirname $FILE)" && pwd )"
Could you give it a try and tell me if you see any problems with it?
Many thanks in advance!
Dimitar
Am Freitag, 4. November 2011, 23:31:27 schrieb Ralf Jung:
Unfortunately all solutions proposed there have problems with relative symlinks, which readlink does not resolve to absolute paths... (I have a symlink in ~/bin called basexhttp pointing to "basex/bin/basexhttp", but it tries to resolve the relative path from the directory I am in, instead of ~/bin)
The shortest one I could come up with that works for me and does not use readlink -e is based on http://stackoverflow.com/questions/1055671/how-can-i- get-the-behavior-of-gnus-readlink-f-on-a-mac
# find Path to this script pushd . > /dev/null SCRIPT_FILE="${BASH_SOURCE[0]}" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")" # we need to get rid of the path part since we cd'ed # Iterate down a (possible) chain of symlinks while [ -L "$SCRIPT_FILE" ] do
SCRIPT_FILE="$(readlink "$SCRIPT_FILE")" cd "$(dirname "$SCRIPT_FILE")" SCRIPT_FILE="$(basename "$SCRIPT_FILE")"done # now we are in the directory we are looking for SCRIPT_DIR="$(pwd -P)" popd > /dev/null
Kind regards, Ralf
On Friday 04 November 2011 23:15:44 Dimitar Popov wrote:
Am Freitag, 4. November 2011, 16:48:10 schrieb Ralf Jung:
there was some shell syntax to do that, but I do not remember it currently.
Again the holy StackOverflow with the help of it's helper St. Google:
http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what- directory-its-stored-in
Cheers, Dimitar
Hey there,
seems to work fine. Running OSX things are a little different anyway in case you installed BaseX from the downloadable disk image to /Applications/ you have to use the startup scripts that come with BaseX.app anyway.
So I guess most OSX won't be affected by this change. I had a quick look at the actual issue and came up with [problem 1, solution 2].
We could maybe change the OSX scripts to call readlink (without -e) (in case calling it with -e failed) to have the actual startscripts reside inside BaseX.app
I'll think about this, for now the solutiono looks fine.
Kind regards Michael
[1] https://github.com/diaspora/diaspora/issues/2020 [2] http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnu... Am 25.10.2011 um 14:44 schrieb Christian Grün:
thanks for the proposal - nitpicks are welcome as well ;) Before applying the changes, I'd like to have some feedback from Mac users, though.. Did someone try the alternative script?
Hi,
any news on this? It seems to work on Mac, and if you are willing to significantly bloat the startup scripts with the shell-equivalent of "readlink -e", you'd even get symlink support for Mac. The much shorter alternative I previously suggested doesn't break anything on Mac either.
Kind regards, Ralf
seems to work fine. Running OSX things are a little different anyway in case you installed BaseX from the downloadable disk image to /Applications/ you have to use the startup scripts that come with BaseX.app anyway.
So I guess most OSX won't be affected by this change. I had a quick look at the actual issue and came up with [problem 1, solution 2].
We could maybe change the OSX scripts to call readlink (without -e) (in case calling it with -e failed) to have the actual startscripts reside inside BaseX.app
I'll think about this, for now the solutiono looks fine.
Kind regards Michael
[1] https://github.com/diaspora/diaspora/issues/2020 [2] http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-g nus-readlink-f-on-a-mac
Am 25.10.2011 um 14:44 schrieb Christian Grün:
thanks for the proposal - nitpicks are welcome as well ;) Before applying the changes, I'd like to have some feedback from Mac users, though.. Did someone try the alternative script?
Ralf,
sorry for delaying your request. I'll update the scripts this week. I'd prefer to have all redundant information in a single script anyway (at least for Linux/Max), so I might do some more rewritings.
Best, Christian ___________________________
On Tue, Nov 1, 2011 at 2:31 PM, Ralf Jung ralfjung-e@gmx.de wrote:
Hi,
any news on this? It seems to work on Mac, and if you are willing to significantly bloat the startup scripts with the shell-equivalent of "readlink -e", you'd even get symlink support for Mac. The much shorter alternative I previously suggested doesn't break anything on Mac either.
Kind regards, Ralf
seems to work fine. Running OSX things are a little different anyway in case you installed BaseX from the downloadable disk image to /Applications/ you have to use the startup scripts that come with BaseX.app anyway.
So I guess most OSX won't be affected by this change. I had a quick look at the actual issue and came up with [problem 1, solution 2].
We could maybe change the OSX scripts to call readlink (without -e) (in case calling it with -e failed) to have the actual startscripts reside inside BaseX.app
I'll think about this, for now the solutiono looks fine.
Kind regards Michael
[1] https://github.com/diaspora/diaspora/issues/2020 [2] http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-g nus-readlink-f-on-a-mac
Am 25.10.2011 um 14:44 schrieb Christian Grün:
thanks for the proposal - nitpicks are welcome as well ;) Before applying the changes, I'd like to have some feedback from Mac users, though.. Did someone try the alternative script?
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Dimitar Popov -
Jens Erat -
Michael Seiferle -
Ralf Jung