Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Tue, May 20, 2014 at 5:59 PM, Michael Biebl mbi...@gmail.com wrote: 2014-05-20 10:58 GMT+02:00 Umut Tezduyar Lindskog u...@tezduyar.com: On Fri, May 16, 2014 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: If it is desirable to cross-build systemd on such an old distribution I'd recommend sticking an alternative ln implementation into $PATH and making sure it is preferred when building systemd. This could just be the shell script that was posted and it could handle --relative invocations, and for everything else defer immediately to the real ln... I was under the impression that you are willing to take a patch but I also see Kay's point. We will try to solve it on our side. Thanks for all the comments, especially to Harald for sharing his script. One note though, the problem happens in Debian stable and I think it is quite early to mark it as such an old distribution. JFTR: Debian stable ships coreutils 8.13, which has been released 08-Sep-2011. So yes, this version is a bit dated and it's unfortunate that this complicates providing backports for newer systemd versions or doing crossbuilds. Umut, you could try to poke the coreutils maintainer to provide a backport of coreutils 8.21, which is currently in jessie. Thanks Michael. Doesn't sound like a bad idea. Umut Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Fri, May 16, 2014 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 16.05.14 13:15, Harald Hoyer (harald.ho...@gmail.com) wrote: On 16.05.2014 13:00, Kay Sievers wrote: I do not think we should do such hacks in upstream systemd. It is a commonly available feature since quite some years, and building without chroot on old systems is a bit too exotic to justify carrying this rather large work around upstream. We do not accept distro-specific, not commonly needed things in the upstream code base because we do not want to maintain them, the same seems to apply to this. Thanks, Kay Then we should probably check, if ln supports --relative and does it right in configure. Yeah, thinking about this I agree with Kay and Harald. If it is desirable to cross-build systemd on such an old distribution I'd recommend sticking an alternative ln implementation into $PATH and making sure it is preferred when building systemd. This could just be the shell script that was posted and it could handle --relative invocations, and for everything else defer immediately to the real ln... I was under the impression that you are willing to take a patch but I also see Kay's point. We will try to solve it on our side. Thanks for all the comments, especially to Harald for sharing his script. One note though, the problem happens in Debian stable and I think it is quite early to mark it as such an old distribution. Umut I have now added a configure check that makes sure that ln supports --relative, so that this is detected early on. Hope that makes sense... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Tue, 20.05.14 10:58, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Yeah, thinking about this I agree with Kay and Harald. If it is desirable to cross-build systemd on such an old distribution I'd recommend sticking an alternative ln implementation into $PATH and making sure it is preferred when building systemd. This could just be the shell script that was posted and it could handle --relative invocations, and for everything else defer immediately to the real ln... I was under the impression that you are willing to take a patch but I Yeah, I was willing to, Kay just convinced me otherwise... It's all Kay's fault! ;-) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
2014-05-20 10:58 GMT+02:00 Umut Tezduyar Lindskog u...@tezduyar.com: On Fri, May 16, 2014 at 4:14 PM, Lennart Poettering lenn...@poettering.net wrote: If it is desirable to cross-build systemd on such an old distribution I'd recommend sticking an alternative ln implementation into $PATH and making sure it is preferred when building systemd. This could just be the shell script that was posted and it could handle --relative invocations, and for everything else defer immediately to the real ln... I was under the impression that you are willing to take a patch but I also see Kay's point. We will try to solve it on our side. Thanks for all the comments, especially to Harald for sharing his script. One note though, the problem happens in Debian stable and I think it is quite early to mark it as such an old distribution. JFTR: Debian stable ships coreutils 8.13, which has been released 08-Sep-2011. So yes, this version is a bit dated and it's unfortunate that this complicates providing backports for newer systemd versions or doing crossbuilds. Umut, you could try to poke the coreutils maintainer to provide a backport of coreutils 8.21, which is currently in jessie. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Fri, May 16, 2014 at 12:30 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 07.05.14 08:54, Emil Sjölin (emil.sjo...@axis.com) wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut
-d '.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 |
cut -d '.' -f 2`
Isn't head -n 1 more correct?
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8
-a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed
s:ln:$srcdir\/tools\/lnr.sh:)
Shouldn't this be sed -e?
+fi
+fi
Hmm, if we ship this anyway, why not always use it? Otherwise it would
too easily bitrot...
THis would also allow removing much of the shell pipeline in the
configure script for this. I mean, these commands have changed all the
time in the past, for example sed quite a bit...
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
No shebang?
+# This script makes the 'ln --relative' command work as expected on a
system where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see
man page
+# for the 'ln' command for the different forms).
+#
+
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string =
$relop_2 ]; then
Why not -o instead of ] || [?
I'd really prefer if somebody who's a true shell guru could look over
this. Harald? (Or Zbigniew?)
I do not think we should do such hacks in upstream systemd.
It is a commonly available feature since quite some years, and
building without chroot on old systems is a bit too exotic to justify
carrying this rather large work around upstream.
We do not accept distro-specific, not commonly needed things in the
upstream code base because we do not want to maintain them, the same
seems to apply to this.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On 16.05.2014 13:00, Kay Sievers wrote: I do not think we should do such hacks in upstream systemd. It is a commonly available feature since quite some years, and building without chroot on old systems is a bit too exotic to justify carrying this rather large work around upstream. We do not accept distro-specific, not commonly needed things in the upstream code base because we do not want to maintain them, the same seems to apply to this. Thanks, Kay Then we should probably check, if ln supports --relative and does it right in configure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Fri, 16.05.14 13:15, Harald Hoyer (harald.ho...@gmail.com) wrote: On 16.05.2014 13:00, Kay Sievers wrote: I do not think we should do such hacks in upstream systemd. It is a commonly available feature since quite some years, and building without chroot on old systems is a bit too exotic to justify carrying this rather large work around upstream. We do not accept distro-specific, not commonly needed things in the upstream code base because we do not want to maintain them, the same seems to apply to this. Thanks, Kay Then we should probably check, if ln supports --relative and does it right in configure. Yeah, thinking about this I agree with Kay and Harald. If it is desirable to cross-build systemd on such an old distribution I'd recommend sticking an alternative ln implementation into $PATH and making sure it is preferred when building systemd. This could just be the shell script that was posted and it could handle --relative invocations, and for everything else defer immediately to the real ln... I have now added a configure check that makes sure that ln supports --relative, so that this is detected early on. Hope that makes sense... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
Hi,
Please review the patch and let us know if anything needs to be
changed. It would be nice if we can get this in before 213.
Umut
On Wed, May 7, 2014 at 8:54 AM, Emil Sjölin emil.sjo...@axis.com wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 2`
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8
-a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed s:ln:$srcdir\/tools\/lnr.sh:)
+fi
+fi
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
+# This script makes the 'ln --relative' command work as expected on a system
where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see man
page
+# for the 'ln' command for the different forms).
+#
+
+
+relative_file() {
+ # Calculate the relative path from $1 to $2.
+ # $1 and $2 are files (including paths).
+
+ source=$(dirname $1)
+ target=$(dirname $2)
+
+ # Make the paths absolute
+ [ ${source#/} != $source ] || source=$(pwd)/$source
+ [ ${target#/} != $target ] || target=$(pwd)/$target
+
+ common_part=$source
+ result=
+
+ while [ ${target#$common_part} = ${target} ]; do
+ # No match, means that the candidate common part is not
correct
+ # Go up one level (reduce common part)
+ common_part=$(dirname $common_part)
+ # and record that we went back, with correct / handling
+ if [ -z $result ]; then
+ result=..
+ else
+ result=../$result
+ fi
+ done
+
+ if [ $common_part = / ]; then
+ # Special case for root (no common path)
+ result=$result/
+ fi
+
+ # Since we now have identified the common part,compute the non-common
+ # part
+ forward_part=${target#$common_part}
+
+ # And now stick all parts together
+ result=$result$forward_part
+ result=${result%/}
+ result=$result/$(basename $2)
+ result=${result#/}
+
+ echo $result
+}
+
+
+# relative options
+relop_1=--relative
+relop_2=-r
+
+# indicates if the relative option is used
+relative_option=no
+
+# the new command line
+new_cmd=ln
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string = $relop_2 ];
then
+ relative_option=yes
+ else
+ # add option to new command line
+ new_cmd=$new_cmd $string
+ fi
+ fi
+ shift
+done
+
+if [ $relative_option = yes ]; then
+ new_cmd=$new_cmd $(relative_file $2 $1) $2
+else
+ new_cmd=$new_cmd $1 $2
+fi
+
+eval $new_cmd
+
+exit 0
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Wed, 07.05.14 08:54, Emil Sjölin (emil.sjo...@axis.com) wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 |
cut -d '.' -f 2`
Isn't head -n 1 more correct?
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8
-a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed
s:ln:$srcdir\/tools\/lnr.sh:)
Shouldn't this be sed -e?
+fi
+fi
Hmm, if we ship this anyway, why not always use it? Otherwise it would
too easily bitrot...
THis would also allow removing much of the shell pipeline in the
configure script for this. I mean, these commands have changed all the
time in the past, for example sed quite a bit...
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
No shebang?
+# This script makes the 'ln --relative' command work as expected on a system
where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see man
page
+# for the 'ln' command for the different forms).
+#
+
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string =
$relop_2 ]; then
Why not -o instead of ] || [?
I'd really prefer if somebody who's a true shell guru could look over
this. Harald? (Or Zbigniew?)
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Fri, May 16, 2014 at 12:30:45AM +0200, Lennart Poettering wrote:
On Wed, 07.05.14 08:54, Emil Sjölin (emil.sjo...@axis.com) wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
This error message is wrong: there was no request. It should be something
like ln is required.
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut
-d '.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 |
cut -d '.' -f 2`
Isn't head -n 1 more correct?
+if test $ln_version_major -lt 8 || test $ln_version_major -eq
8 -a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed
s:ln:$srcdir\/tools\/lnr.sh:)
The quoting here is ... complicated. If you count the quotes, what is
effectively
quoted are strings ln, \/tools\/lnr.sh. They don't contain shell special
characters,
so there's no need to quote them. OTOH, the parts which are _not_ quoted, might.
And why are slashes escaped?
LN_S=$(echo $LN_S | sed -E s|^[^ ]+|${srcdir}/tools/lnr.sh|)
This form has the advantage that it'll work if $LN_S e.g. has /bin/ln not ln,
and also if ${srcdir} contains spaces.
Shouldn't this be sed -e?
It's fine here, because no file is given.
+fi
+fi
Hmm, if we ship this anyway, why not always use it? Otherwise it would
too easily bitrot...
THis would also allow removing much of the shell pipeline in the
configure script for this. I mean, these commands have changed all the
time in the past, for example sed quite a bit...
Yeah, probably it's better to use it unconditionally. This will rid us of
the ugly version checks.
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
No shebang?
+# This script makes the 'ln --relative' command work as expected on a
system where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see
man page
+# for the 'ln' command for the different forms).
+#
+
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string =
$relop_2 ]; then
Why not -o instead of ] || [?
I'd really prefer if somebody who's a true shell guru could look over
this. Harald? (Or Zbigniew?)
If I review it, do I get to become a true shell guru? ;)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93 ++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 2`
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8 -a
$ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed s:ln:$srcdir\/tools\/lnr.sh:)
+fi
+fi
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable modules
support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
+# This script makes the 'ln --relative' command work as expected on a system
where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see man
page
+# for the 'ln' command for the different forms).
+#
+
+
+relative_file() {
+ # Calculate the relative path from $1 to $2.
+ # $1 and $2 are files (including paths).
+
+ source=$(dirname $1)
+ target=$(dirname $2)
+
+ # Make the paths absolute
+ [ ${source#/} != $source ] || source=$(pwd)/$source
+ [ ${target#/} != $target ] || target=$(pwd)/$target
+
+ common_part=$source
+ result=
+
+ while [ ${target#$common_part} = ${target} ]; do
+ # No match, means that the candidate common part is not correct
+ # Go up one level (reduce common part)
+ common_part=$(dirname $common_part)
+ # and record that we went back, with correct / handling
+ if [ -z $result ]; then
+ result=..
+ else
+ result=../$result
+ fi
+ done
+
+ if [ $common_part = / ]; then
+ # Special case for root (no common path)
+ result=$result/
+ fi
+
+ # Since we now have identified the common part,compute the non-common
+ # part
+ forward_part=${target#$common_part}
+
+ # And now stick all parts together
+ result=$result$forward_part
+ result=${result%/}
+ result=$result/$(basename $2)
+ result=${result#/}
+
+ echo $result
+}
+
+
+# relative options
+relop_1=--relative
+relop_2=-r
+
+# indicates if the relative option is used
+relative_option=no
+
+# the new command line
+new_cmd=ln
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string = $relop_2 ];
then
+ relative_option=yes
+ else
+ # add option to new command line
+ new_cmd=$new_cmd $string
+ fi
+ fi
+ shift
+done
+
+if [ $relative_option = yes ]; then
+ new_cmd=$new_cmd $(relative_file $2 $1) $2
+else
+ new_cmd=$new_cmd $1 $2
+fi
+
+eval $new_cmd
+
+exit 0
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
