[pacman-dev] [PATCH] Replace usage of "cp -s" with the more portable "ln -s"
The "-s" argument does not exist on BSD, and neither does "--remove-destination". This patch replaces the calls to "cp -s --remove-destination" with the equivalent "rm -f" and "ln -s" calls, in order to increase portability. Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- scripts/makepkg.sh.in | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index f56bcda..9da3687 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -435,11 +435,13 @@ download_sources() { local file=$(strip_url "$netfile") if [ -f "$startdir/$file" ]; then msg2 "$(gettext "Found %s in build dir")" "$file" - cp -s --remove-destination "$startdir/$file" "$srcdir/" + rm -f "$srcdir/$file" + ln -s "$startdir/$file" "$srcdir/" continue elif [ -f "$SRCDEST/$file" ]; then msg2 "$(gettext "Using cached copy of %s")" "$file" - cp -s --remove-destination "$SRCDEST/$file" "$srcdir/" + rm -f "$srcdir/$file" + ln -s "$SRCDEST/$file" "$srcdir/" continue fi @@ -464,7 +466,8 @@ download_sources() { if echo "$dlclient" | grep -q "%o" ; then mv -f "$SRCDEST/$file.part" "$SRCDEST/$file" fi - cp -s --remove-destination "$SRCDEST/$file" "$srcdir/" + rm -f "$srcdir/$file" + ln -s "$SRCDEST/$file" "$srcdir/" done popd &>/dev/null -- 1.5.4.5
The equivalent of the "-i" argument for file on Linux is "-I" on BSD. Both version allow the use of the long option "--mime". Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 9da3687..ce5ac3f 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -606,7 +606,7 @@ extract_sources() { fi # fix flyspray #6246 - local file_type=$(file -bizL "$file") + local file_type=$(file -bzL --mime "$file") local cmd='' case "$file_type" in *application/x-tar*|*application/zip*|*application/x-zip*|*application/x-cpio*) -- 1.5.4.5
The equivalent of the "-i" argument for file on Linux is "-I" on BSD. Both version allow the use of the long option "--mime".
Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- This seems fine, but the Arch manpage we have for file is from the BSD General Commands Manual and documents both -i and --mime. I do see
On Tue, May 20, 2008 at 12:51 PM, Sebastian Nowicki <sebnow@gmail.com> wrote: that it is a 2008 revision, so perhaps older BSDs do not have the -i option. Seems OK otherwise- Xavier, feel free to queue this up if you are OK with it.
scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 9da3687..ce5ac3f 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -606,7 +606,7 @@ extract_sources() { fi
# fix flyspray #6246 - local file_type=$(file -bizL "$file") + local file_type=$(file -bzL --mime "$file") local cmd='' case "$file_type" in *application/x-tar*|*application/zip*|*application/x-zip*|*application/x-cpio*) -- 1.5.4.5
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
On Tue, May 20, 2008 at 9:29 PM, Dan McGee <dpmcgee@gmail.com> wrote:
The equivalent of the "-i" argument for file on Linux is "-I" on BSD. Both version allow the use of the long option "--mime".
Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- This seems fine, but the Arch manpage we have for file is from the BSD General Commands Manual and documents both -i and --mime. I do see
On Tue, May 20, 2008 at 12:51 PM, Sebastian Nowicki <sebnow@gmail.com> wrote: that it is a 2008 revision, so perhaps older BSDs do not have the -i option. Seems OK otherwise- Xavier, feel free to queue this up if you are OK with it.
That parameter naming difference looks very stupid to me, but well, that is a simple workaround so I am ok with it.
Sebastian Nowicki wrote:
The equivalent of the "-i" argument for file on Linux is "-I" on BSD. Both version allow the use of the long option "--mime".
I checked freebsd and netbsd man pages, both seem to use -i as well. I could not check openbsd one, the page is unavailable. Where can we find other (older?) bsd man pages?
On 26/05/2008, at 12:08 AM, Xavier wrote:
Sebastian Nowicki wrote:
The equivalent of the "-i" argument for file on Linux is "-I" on BSD. Both version allow the use of the long option "--mime".
I checked freebsd and netbsd man pages, both seem to use -i as well. I could not check openbsd one, the page is unavailable. Where can we find other (older?) bsd man pages?
I thought I sent a mail about that earlier, but I guess it didn't go through. -I is used on Mac OSX. When sending the patch I thought I checked that this was the case in other BSD man pages, but I must have confused that with something else. From the Mac OSX (Leopard 1.5) man page:
-I, --mime Causes the file command to output mime type strings rather than the more traditional human readable ones. Thus it may say ``text/plain; charset=us-ascii'' rather than ``ASCII text''. In order for this option to work, file changes the way it han- dles files recognised by the command itself (such as many of the text file types, directories etc), and makes use of an alternative ``magic'' file. (See ``FILES'' section, below).
-i If the file is a regular file do not classify its contents.
You can find the online copy here: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/file... I just looked through it again and it appears there's a "legacy" section, which does use the lower case -i… -- Sebastian Nowicki
Sebastian Nowicki wrote:
I thought I sent a mail about that earlier, but I guess it didn't go through. -I is used on Mac OSX. When sending the patch I thought I checked that this was the case in other BSD man pages, but I must have confused that with something else.
You can find the online copy here: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/file...
I just looked through it again and it appears there's a "legacy" section, which does use the lower case -i…
I was fine with this change because it thought it was needed for every BSD platform, but seeing it is just a mac osx change almost makes me want to reconsider. Why did they change that? And if you just use COMMAND_MODE=legacy to restore the normal interface, this patch is no longer needed?
On 26/05/2008, at 2:38 PM, Xavier wrote:
I was fine with this change because it thought it was needed for every BSD platform, but seeing it is just a mac osx change almost makes me want to reconsider.
I thought it was a more worthwhile patch as well.
And if you just use COMMAND_MODE=legacy to restore the normal interface, this patch is no longer needed?
Yes, it works:
COMMAND_MODE=legacy file -bziL libfetch-6.2.0.0.tar.bz2 application/x-tar (application/x-bzip2)
Some change to the code would still be required though, like setting the environment variable. I don't think it would be very elegant to require the user to set the environment variable. -- Sebastian Nowicki
On Mon, May 26, 2008 at 12:47 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On 26/05/2008, at 2:38 PM, Xavier wrote:
I was fine with this change because it thought it was needed for every BSD platform, but seeing it is just a mac osx change almost makes me want to reconsider.
I thought it was a more worthwhile patch as well.
And if you just use COMMAND_MODE=legacy to restore the normal interface, this patch is no longer needed?
Yes, it works:
COMMAND_MODE=legacy file -bziL libfetch-6.2.0.0.tar.bz2 application/x-tar (application/x-bzip2)
Some change to the code would still be required though, like setting the environment variable. I don't think it would be very elegant to require the user to set the environment variable.
Well maybe I would prefer this solution, adding this somewhere in makepkg : export COMMAND_MODE=legacy Can you confirm it works that way too? I think it would also be safer. For instance, you forgot the second file call. But also in the future if these file commands are modified or new ones are added, it would be better to just have the above export. Though I suppose this env var is only used by macos and would have no influence on other systems, right? So as always, some testing would be appreciated before we put this in makepkg :)
On 26/05/2008, at 7:04 PM, Xavier wrote:
Well maybe I would prefer this solution, adding this somewhere in makepkg : export COMMAND_MODE=legacy Can you confirm it works that way too?
I think it would also be safer. For instance, you forgot the second file call. But also in the future if these file commands are modified or new ones are added, it would be better to just have the above export. Though I suppose this env var is only used by macos and would have no influence on other systems, right? So as always, some testing would be appreciated before we put this in makepkg :)
I'm currently testing makepkg with exported COMMAND_MODE=legacy, and it seems to be working fine, but I'll test it a bit more and send a patch later in the day. I was looking into COMMAND_MODE a bit more, and found something that is a bit bazaar. It appears that OSX's current utilities conform to the UNIX 03 specification. So OSX is more UNIX compliant than BSD and Linux… that's a bit surprising. From http://developer.apple.com/documentation/Darwin/Reference/ManPages/man5/comp...
Setting the environment variable COMMAND_MODE to the value legacy causes utility programs to behave as closely to Mac OS X 10.3's utility programs as possible. When in this mode all of 10.3's flags are accepted, and in some cases extra flags are accepted, but no flags that were used in 10.3 will have been removed or changed in meaning. Any behavioral changes in this mode are documented in the LEGACY sections of the individual utilities.
Setting the environment variable COMMAND_MODE to the value unix03 causes utility programs to obey the Version 3 of the Single UNIX Specification (``SUSv3'') standards even if doing so would alter the behavior of flags used in 10.3.
The value of COMMAND_MODE is case insensitive and if it is unset or set to something other than legacy or unix03 it behaves as if it were set to unix03.
The change to file and other utilities are probably new to Leopard, since that's when OSX got UNIX certification. -- Sebastian Nowicki
For some reason `file` on Mac OSX has different arguments than BSD and Linux; -i no longer prints out the mime strings. With the environment variable COMMAND_MODE set to "legacy", `file` behaves more like it does on Linux and BSD, i.e., `file -i` prints the mime type. Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- scripts/makepkg.sh.in | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 91b05f1..aa0b99e 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -32,6 +32,8 @@ # gettext initialization export TEXTDOMAIN='pacman' export TEXTDOMAINDIR='@localedir@' +# necessary to achieve consistent behavior for `file` on Mac OSX +export COMMAND_MODE=legacy myver='@PACKAGE_VERSION@' confdir='@sysconfdir@' -- 1.5.5.1
On Tue, May 27, 2008 at 2:23 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
For some reason `file` on Mac OSX has different arguments than BSD and Linux; -i no longer prints out the mime strings. With the environment variable COMMAND_MODE set to "legacy", `file` behaves more like it does on Linux and BSD, i.e., `file -i` prints the mime type.
Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- scripts/makepkg.sh.in | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 91b05f1..aa0b99e 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -32,6 +32,8 @@ # gettext initialization export TEXTDOMAIN='pacman' export TEXTDOMAINDIR='@localedir@' +# necessary to achieve consistent behavior for `file` on Mac OSX +export COMMAND_MODE=legacy Use '' (quotes) like every other variable here, but otherwise looks fine. I think this is the best solution to the problem. And concise is fine: # file -i is broken on Mac OSX unless legacy mode is set or at least I consider it broken. :)
myver='@PACKAGE_VERSION@' confdir='@sysconfdir@' -- Acked-by: Dan McGee <dan@archlinux.org>
On Tue, May 27, 2008 at 2:39 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, May 27, 2008 at 2:23 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
For some reason `file` on Mac OSX has different arguments than BSD and Linux; -i no longer prints out the mime strings. With the environment variable COMMAND_MODE set to "legacy", `file` behaves more like it does on Linux and BSD, i.e., `file -i` prints the mime type.
Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- scripts/makepkg.sh.in | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 91b05f1..aa0b99e 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -32,6 +32,8 @@ # gettext initialization export TEXTDOMAIN='pacman' export TEXTDOMAINDIR='@localedir@' +# necessary to achieve consistent behavior for `file` on Mac OSX +export COMMAND_MODE=legacy Use '' (quotes) like every other variable here, but otherwise looks fine. I think this is the best solution to the problem. And concise is fine: # file -i is broken on Mac OSX unless legacy mode is set or at least I consider it broken. :)
myver='@PACKAGE_VERSION@' confdir='@sysconfdir@' -- Acked-by: Dan McGee <dan@archlinux.org>
Ack to Dan's comments. Acked-by: Aaron Griffin <aaronmgriffin@gmail.com>
On Tue, May 27, 2008 at 9:39 PM, Dan McGee <dpmcgee@gmail.com> wrote:
# file -i is broken on Mac OSX unless legacy mode is set or at least I consider it broken. :)
As Xilon pointed out, the compat man page states that Mac OSX is compliant to sus3. Well maybe we can say that sus3 is broken but that is different. Just saying that file -i does not work should be enough. I am curious about how file interface is defined in posix and sus3 though. And I didn't even hear about sus3 before. http://en.wikipedia.org/wiki/Single_UNIX_Specification "In the early 1990s, a separate effort known as the Common API Specification or Spec 1170 was initiated by several major vendors, who formed the COSE alliance in the wake of the Unix wars. This specification became more popular because it was available at no cost, whereas the IEEE charged a substantial fee for access to the POSIX specification."
On Tue, May 20, 2008 at 12:51 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
The "-s" argument does not exist on BSD, and neither does "--remove-destination". This patch replaces the calls to "cp -s --remove-destination" with the equivalent "rm -f" and "ln -s" calls, in order to increase portability.
Signed-off-by: Sebastian Nowicki <sebnow@gmail.com> --- Ahh, I think this is smart as long as we have identical behavior as before. The one thing I may ask, and do not know if this patch does since I haven't actually tested it, is can we make the symlinks in download_sources() relative for files in the build dir? This would make it easier to move your build directory without breaking everything.
For example, instead of a symlink looking like this (in src/): foobar.desktop -> /home/dmcgee/packages/foobar/foobar.desktop It would be: foobar.desktop -> ../foobar.desktop -Dan
scripts/makepkg.sh.in | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index f56bcda..9da3687 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -435,11 +435,13 @@ download_sources() { local file=$(strip_url "$netfile") if [ -f "$startdir/$file" ]; then msg2 "$(gettext "Found %s in build dir")" "$file" - cp -s --remove-destination "$startdir/$file" "$srcdir/" + rm -f "$srcdir/$file" + ln -s "$startdir/$file" "$srcdir/" continue elif [ -f "$SRCDEST/$file" ]; then msg2 "$(gettext "Using cached copy of %s")" "$file" - cp -s --remove-destination "$SRCDEST/$file" "$srcdir/" + rm -f "$srcdir/$file" + ln -s "$SRCDEST/$file" "$srcdir/" continue fi
@@ -464,7 +466,8 @@ download_sources() { if echo "$dlclient" | grep -q "%o" ; then mv -f "$SRCDEST/$file.part" "$SRCDEST/$file" fi - cp -s --remove-destination "$SRCDEST/$file" "$srcdir/" + rm -f "$srcdir/$file" + ln -s "$SRCDEST/$file" "$srcdir/" done
popd &>/dev/null -- 1.5.4.5
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
On Tue, May 20, 2008 at 9:33 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Ahh, I think this is smart as long as we have identical behavior as before. The one thing I may ask, and do not know if this patch does since I haven't actually tested it, is can we make the symlinks in download_sources() relative for files in the build dir? This would make it easier to move your build directory without breaking everything.
For example, instead of a symlink looking like this (in src/): foobar.desktop -> /home/dmcgee/packages/foobar/foobar.desktop It would be: foobar.desktop -> ../foobar.desktop
I think that issue is a bit orthogonal. Also it seems to defeat the recent idea from grabler of having $pkgdir and $srcdir independent, for putting them somewhere else like in tmpfs or whatever. In any cases, I think it is better to just take the patch as is. We can worry about other stuff later.
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Sebastian Nowicki
-
Xavier