Re: Bug#565218: info boilerplate on man page gives only the hard way
> "MS" == Michael Stone writes: MS> On Thu, Jan 14, 2010 at 06:00:17AM +0800, jida...@jidanni.org wrote: >> Well, it turns out that we find we often can also just do >> $ info WHATEVER MS> Yes, that's why it used to say that. But if something goes wrong with MS> info, that invocation will fall back to displaying the man page, and MS> then we get a bunch of bug reports complaining that the info page is MS> the same as the man page. So, that's why I suggested saying __both__ methods. But you already closed the bug before reading to the end.
Bug#565218: info boilerplate on man page gives only the hard way
X-debbugs-cc: bug-coreutils@gnu.org Package: coreutils Version: 8.1-1 Severity: wishlist We see many The full documentation for WHATEVER is maintained as a Texinfo manual. If the info and WHATEVER programs are properly installed at your site, the command info coreutils 'WHATEVER invocation' should give you access to the complete manual. Well, it turns out that we find we often can also just do $ info WHATEVER Therefore perhaps say info coreutils 'WHATEVER invocation or often just info WHATEVER or something like that.
coreutils-8.4 released [stable]
This is to announce coreutils-8.4, a bug-fix-only "stable" release. The main purpose of this release is to fix a build failure on some systems using glibc-2.7..2.9. Here's the GNU Coreutils home page, in case you're wondering what it is: http://www.gnu.org/software/coreutils/ Thanks to everyone else who has been contributing, helping to manage the mailing list and reporting bugs. For a summary of changes and contributors, see: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v8.4 or run this command from a git-cloned coreutils directory: git shortlog v8.3..v8.4 To summarize the gnulib-related changes, run these commands from a git-cloned coreutils directory: git checkout v8.4 git submodule summary v8.3 Here are the compressed sources: ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.4.tar.gz (11 MB) ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.4.tar.xz (4.3 MB) Here are the GPG detached signatures[*]: ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.4.tar.gz.sig ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.4.tar.xz.sig To reduce load on the main server, use a mirror listed at: http://www.gnu.org/order/ftp.html [*] You can use either of the above signature files to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify coreutils-8.4.tar.xz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys B9AB9A16 and rerun the `gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.65.23-13e35 Automake 1.11a Gnulib v0.0-3307-g7521ea0 Bison 2.4.460-505e ./NEWS * Noteworthy changes in release 8.4 (2010-01-13) [stable] ** Bug fixes nproc --all is now guaranteed to be as large as the count of available processors, which may not have been the case on GNU/Linux systems with neither /proc nor /sys available. [bug introduced in coreutils-8.1] ** Build-related Work around a build failure when using buggy . Alternatively, configure with --disable-libcap. Compilation would fail on systems using glibc-2.7..2.9 due to changes in gnulib's wchar.h that tickled a bug in at least those versions of glibc's own header. Now, gnulib works around the bug in those older glibc headers. Building would fail with a link error (cp/copy.o) when XATTR headers were installed without the corresponding library. Now, configure detects that and disables xattr support, as one would expect. pgpJ6tmiNUcGH.pgp Description: PGP signature
Re: [PATCH] tests: don't silently skip the sort-version tests
Eric Blake wrote: > According to Jim Meyering on 1/13/2010 2:26 AM: >> The behavior of bash via /bin/sh (same for zsh and dash, though without >> the warning) is probably POSIX-conforming, but this example illustrates >> why it would be better to emulate openBSD's /bin/sh. >> >> * tests/misc/sort-version: Don't use <<- and indented here-doc contents. >> s/<<-/<> bash would ignore the indented delimiter and use EOF, thus silently >> skipping this test. > > Actually, this was a regression caused by your conversion from space to > tab indentation. POSIX states: "If the redirection symbol is "<<-" , all s/space to tab/tab to space/ > leading characters shall be stripped from input lines and the line > containing the trailing delimiter." Ha! Thanks for pointing that out. This is the first snag I've encountered with that conversion. I'm glad I'm the one who fixed it.
Re: [PATCH] tests: don't silently skip the sort-version tests
According to Jim Meyering on 1/13/2010 2:26 AM:
> The behavior of bash via /bin/sh (same for zsh and dash, though without
> the warning) is probably POSIX-conforming, but this example illustrates
> why it would be better to emulate openBSD's /bin/sh.
>
> * tests/misc/sort-version: Don't use <<- and indented here-doc contents.
> s/<<-/< bash would ignore the indented delimiter and use EOF, thus silently
> skipping this test.
Actually, this was a regression caused by your conversion from space to
tab indentation. POSIX states: "If the redirection symbol is "<<-" , all
leading characters shall be stripped from input lines and the line
containing the trailing delimiter." So it is only _required_ to work with
tabs; using spaces gives arbitrary results.
> OpenBSD5.4's shell reported the failure:
> $ printf 'cat<<-x\n foo\n x\n'|sh
> sh: [4]: here document `x' unclosed
> [Exit 1]
> by contrast, bash warns but still exits successfully:
> $ printf 'cat<<-x\n foo\n x\n'|bash && echo you lose
> bash: line 3: warning: here-document at line 1 delimited by \
> end-of-file (wanted `x')
>foo
>x
> you lose
As proof, bash behaves just fine when you obey POSIX:
$ printf 'cat <<-x\n\thi\n\tx\n'|bash && echo you lose
hi
We should mention this in the autoconf manual, so I'm pushing this. I'm
not (yet) sure whether the warning about unterminated here-doc was
introduced in bash 4.0 or bash 4.1, but I can also confirm that bash 3.2
is silent whereas bash 4.1 warns (but the warning is longer than 80
columns, so it is not a nice fit in the manual).
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
From f4fc1ad9bbd765a84dd6033e03541ffde9c7c045 Mon Sep 17 00:00:00 2001
From: Eric Blake
Date: Wed, 13 Jan 2010 06:03:07 -0700
Subject: [PATCH] Document here-doc pitfall.
* doc/autoconf.texi (Here-Documents): Mention problem with <<-
operator.
Reported by Jim Meyering.
Signed-off-by: Eric Blake
---
ChangeLog |7 +++
doc/autoconf.texi | 16
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6b6fd80..3fa0c5d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-01-13 Eric Blake
+
+ Document here-doc pitfall.
+ * doc/autoconf.texi (Here-Documents): Mention problem with <<-
+ operator.
+ Reported by Jim Meyering.
+
2010-01-12 Eric Blake
Typo fix in earlier commit.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ce6ac88..31550fd 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -14691,6 +14691,22 @@ Here-Documents
condition turned out to be false at runtime, and we end up not
executing the macro at all.
+Be careful with the use of @samp{<<-} to unindent here-documents. The
+behavior is only portable for stripping leading @key{TAB}s, and things
+can silently break if an overzealous editor converts to using leading
+spaces (not all shells are nice enough to warn about unterminated
+here-documents).
+
+...@example
+$ @kbd{printf 'cat <<-x\n\t1\n\t 2\n\tx\n' | bash && echo oops}
+1
+ 2
+$ @kbd{printf 'cat <<-x\n 1\n 2\n x\n' | bash-3.2 && echo oops}
+ 1
+ 2
+ x
+...@end example
+
@node File Descriptors
@section File Descriptors
@cindex Descriptors
--
1.6.4.2
signature.asc
Description: OpenPGP digital signature
Re: new snapshot available: coreutils-8.3.10-a4da4
Eric Blake wrote: > Jim Meyering meyering.net> writes: > >> I'm planning to release coreutils-8.4 tomorrow. >> It will be a build-fix-only release, along with a minor bug fix >> for the relatively new command, nproc. > > 3 failures on Solaris 8, but probably not worth worrying about since that > platform is so old: > > > FAIL: tail-2/inotify-hash-abuse2 (exit: 1) > == ... Thanks for checking/reporting that. That should be fixed by Pádraig's patch. > FAIL: install/install-C (exit: 1) > = > ... > + skip_if_setgid_ > + setgid_tmpdir=setgid-27283 > + umask 77 > + mkdir setgid-27283 > ++ stat --printf %A setgid-27283 > + perms=drwx-- > + rmdir setgid-27283 > + mode1=0644 > + mode2=0755 > + mode3=2755 > + echo test > + echo '`a'\'' -> `b'\''' > + echo 'removed `b'\'' > `a'\'' -> `b'\''' > + : > + ginstall -Cv -m0644 a b > + compare out out_installed_first > + diff -u out out_installed_first > + ginstall -Cv -m0644 a b > + compare out out_empty > + diff -u out out_empty > --- out 2010-01-12 09:15:33.996514000 -0700 > +++ out_empty 2010-01-12 09:15:33.941516000 -0700 > @@ -1,2 +0,0 @@ > -removed `b' > -`a' -> `b' > + fail=1 I've seen this several times already. It'd be good to fix it eventually, if only to avoid spending any more time with failure reports. But since it's related only to install's -C option, it's not a high priority at all. > FAIL: ls/stat-vs-dirent (exit: 1) > = > ... Looks like an oddity at a mount point. I'm happy to leave this one unaddressed, for now. > + st_ino=540483 > + test -n 540399 > + test 540399 '!=' 540483 > + echo './ls/stat-vs-dirent: test failed: /home/Algol1: d_ino(540399) != > st_ino > (540483) > This may indicate a flaw in your kernel or file system implementation. > The flaw isn'\''t serious for coreutils, but it might break other > tools, > so you should report it to your operating system vendor.' > ./ls/stat-vs-dirent: test failed: /home/Algol1: d_ino(540399) != > st_ino(540483) > This may indicate a flaw in your kernel or file system implementation. > The flaw isn't serious for coreutils, but it might break other tools, > so you should report it to your operating system vendor.
Re: openbsd5.4: spurious ls/infloop test failure: due to bug in /bin/sh
According to Jim Meyering on 1/13/2010 2:56 AM:
>
> * tests/ls/infloop: OpenBSD4.5's /bin/sh would mistakenly include
> "set -x"-output in an application's stderr stream when stderr is
> redirected before stdout.
I believe autoconf already covers this one; in the node 'File
Descriptors', so the fix is obviously correct:
> If you intend to redirect both standard error and standard output,
> redirect standard output first. This works better with @acronym{HP-UX},
> since its shell mishandles tracing if standard error is redirected
> first:
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
signature.asc
Description: OpenPGP digital signature
Re: coreutils-8.3: a few tests fail
Pádraig Brady wrote:
> And can be simlified from:
> kill -0 $pid && kill $pid || fail=1
> to:
> kill $pid || fail=1
Thanks!
I prefer yours, and will push it shortly.
> Subject: [PATCH] tests: avoid spurious failures on older shells
>
> * tests/tail-2/inotify-hash-abuse: Use kill rather than wait
> to determine if the tail process is still running.
> * tests/tail-2/inotify-hash-abuse2: Ditto.
> ---
> tests/tail-2/inotify-hash-abuse | 15 +++
> tests/tail-2/inotify-hash-abuse2 | 12 ++--
> 2 files changed, 5 insertions(+), 22 deletions(-)
>
> diff --git a/tests/tail-2/inotify-hash-abuse b/tests/tail-2/inotify-hash-abuse
> index ab5a69e..65a3412 100755
> --- a/tests/tail-2/inotify-hash-abuse
> +++ b/tests/tail-2/inotify-hash-abuse
> @@ -46,23 +46,14 @@ echo a > 1 || fail=1
>
> # Wait up to 2s for the buggy tail to die,
> # or for the "tail: `1' has appeared; following end of new file" output
> -dead=0
> for i in $(seq 10); do
> - kill -0 $pid || { dead=1; break; }
> + kill -0 $pid || break
>grep 'has appeared;' out > /dev/null && break
>sleep .2
> done
>
> -# Fixed tail will not have aborted. Kill it.
> -test $dead = 0 && kill -HUP $pid
> -
> -wait $pid
> -st=$?
> -
> -case $st in
> - 129) ;;
> - *) echo tail died via unexpected signal: $st; fail=1;;
> -esac
> +# Kill the working tail, or fail if it has already aborted
> +kill $pid || fail=1
>
> cat out
>
> diff --git a/tests/tail-2/inotify-hash-abuse2
> b/tests/tail-2/inotify-hash-abuse2
> index 4fe080b..2e567c7 100755
> --- a/tests/tail-2/inotify-hash-abuse2
> +++ b/tests/tail-2/inotify-hash-abuse2
> @@ -36,15 +36,7 @@ for i in $(seq 200); do
>touch f
> done
>
> -# Fixed tail will not have aborted. Kill it.
> -kill -HUP $pid
> -
> -wait $pid
> -st=$?
> -
> -case $st in
> - 129) ;;
> - *) echo tail died via unexpected signal: $st; fail=1;;
> -esac
> +# Kill the working tail, or fail if it has already aborted
> +kill $pid || fail=1
>
> Exit $fail
Re: coreutils-8.3: a few tests fail
Well we're only testing if tail has died I think, so
how about just using `kill -0 $pid` as follows:
diff --git a/tests/tail-2/inotify-hash-abuse b/tests/tail-2/inotify-hash-abuse
index ab5a69e..592022a 100755
--- a/tests/tail-2/inotify-hash-abuse
+++ b/tests/tail-2/inotify-hash-abuse
@@ -46,23 +46,14 @@ echo a > 1 || fail=1
# Wait up to 2s for the buggy tail to die,
# or for the "tail: `1' has appeared; following end of new file" output
-dead=0
for i in $(seq 10); do
- kill -0 $pid || { dead=1; break; }
+ kill -0 $pid || break
grep 'has appeared;' out > /dev/null && break
sleep .2
done
# Fixed tail will not have aborted. Kill it.
-test $dead = 0 && kill -HUP $pid
-
-wait $pid
-st=$?
-
-case $st in
- 129) ;;
- *) echo tail died via unexpected signal: $st; fail=1;;
-esac
+kill -0 $pid && kill $pid || fail=1
cat out
diff --git a/tests/tail-2/inotify-hash-abuse2 b/tests/tail-2/inotify-hash-abuse2
index 4fe080b..ffad623 100755
--- a/tests/tail-2/inotify-hash-abuse2
+++ b/tests/tail-2/inotify-hash-abuse2
@@ -37,14 +37,6 @@ for i in $(seq 200); do
done
# Fixed tail will not have aborted. Kill it.
-kill -HUP $pid
-
-wait $pid
-st=$?
-
-case $st in
- 129) ;;
- *) echo tail died via unexpected signal: $st; fail=1;;
-esac
+kill -0 $pid && kill $pid || fail=1
Exit $fail
Re: coreutils-8.3: a few tests fail
Pádraig Brady wrote: > On 13/01/10 10:51, Jim Meyering wrote: >> Christophe LYON wrote: >>> I have built coreutils-8.3 and ran 'make check' on a few systems and I >>> have noticed some FAILs as follows. Given their old age, I am not sure >>> it is worth reporting, though. >>> >>> * Linux RedHat 3/x86: tail-2/inotify-hash-abuse, log extract: >>>+ kill -HUP 15829 >>> [1]+ Hangup tail $debug -qF $(seq $n)>out 2>&1 >>> + wait 15829 >>> ./tail-2/inotify-hash-abuse: line 59: wait: pid 15829 is not a child >>> of this shell >>> + st=127 >>> + echo tail died via unexpected signal: 127 >>> tail died via unexpected signal: 127 >>> + fail=1 >>> >>> * Linux RedHat 3/x86: tail-2/inotify-hash-abuse2, log extract: >>> + kill -HUP 16044 >>> ./tail-2/inotify-hash-abuse2: line 40: kill: (16044) - No such process >>> + wait 16044 >>> + st=124 >>> + echo tail died via unexpected signal: 124 >>> tail died via unexpected signal: 124 >>> + fail=1 >>> >>> * Linux RedHat 3/x86_64: test-utimens (test-utimens.h:101: assertion failed) >>> >>> * Linux RedHat 4/x86: test-nanosleep (test-nanosleep.c:78: assertion failed) >>> * Linux RedHat 4/x86: test-sleep (test-sleep.c:53: assertion failed) >> >> Thanks for the report. >> Can you repeat the tests with the very latest snapshot? >> >>http://meyering.net/cu/coreutils-ss.tar.gz 9.4 MB >>http://meyering.net/cu/coreutils-ss.tar.xz 4.0 MB >> >> If any of those failures persist, we *might* have time to address >> one or two before coreutils-8.4, which is slated to be released today. > > I think we may be encountering shell issues here? > > We get 127 rather than 129 under dash > once the "hangup" message is displayed before > `wait` is called > > $ /bin/sleep 20 & bg=$! > $ kill -HUP $bg > [1] + Hangup /bin/sleep 20 > $ wait $bg > $ echo $? > 127 I think so to, and had just been working on that. What do you think of these changes? >From 2eb54470541557fd89b934a7b2245fe4b1515b82 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 13 Jan 2010 12:46:25 +0100 Subject: [PATCH] tests: decrease risk of race in tail-2/inotify-hash-abuse2 * tests/tail-2/inotify-hash-abuse2: Try to avoid killing the tail process before we start waiting for it to die. Also, don't assume that kill -HUP is the same as kill -1. Use the latter. Also, always use tail's -s .001 option, to make the non-inotify case act more like the inotify-enabled one. --- tests/tail-2/inotify-hash-abuse2 | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/tests/tail-2/inotify-hash-abuse2 b/tests/tail-2/inotify-hash-abuse2 index 4fe080b..5966b03 100755 --- a/tests/tail-2/inotify-hash-abuse2 +++ b/tests/tail-2/inotify-hash-abuse2 @@ -26,9 +26,9 @@ fi touch f || framework_failure -debug='---disable-inotify -s .001' +debug='---disable-inotify' debug= -timeout 10 tail $debug -F f & pid=$! +timeout 10 tail $debug -s .001 -F f & pid=$! for i in $(seq 200); do kill -0 $pid || break; @@ -37,8 +37,14 @@ for i in $(seq 200); do done # Fixed tail will not have aborted. Kill it. -kill -HUP $pid +( touch witness; sleep 1; kill -1 $pid ) & +# Wait for the killer subshell to start, so that we decrease the +# risk of 'wait'ing *after* the tail process has been killed. +until test -f witness; do :; done + +# Hope that we begin to wait for $pid before it is killed. +# FIXME: this is racy... wait $pid st=$? -- 1.6.6.511.gf46c4
Re: coreutils-8.3: a few tests fail
On 13/01/10 10:51, Jim Meyering wrote: Christophe LYON wrote: I have built coreutils-8.3 and ran 'make check' on a few systems and I have noticed some FAILs as follows. Given their old age, I am not sure it is worth reporting, though. * Linux RedHat 3/x86: tail-2/inotify-hash-abuse, log extract: + kill -HUP 15829 [1]+ Hangup tail $debug -qF $(seq $n)>out 2>&1 + wait 15829 ./tail-2/inotify-hash-abuse: line 59: wait: pid 15829 is not a child of this shell + st=127 + echo tail died via unexpected signal: 127 tail died via unexpected signal: 127 + fail=1 * Linux RedHat 3/x86: tail-2/inotify-hash-abuse2, log extract: + kill -HUP 16044 ./tail-2/inotify-hash-abuse2: line 40: kill: (16044) - No such process + wait 16044 + st=124 + echo tail died via unexpected signal: 124 tail died via unexpected signal: 124 + fail=1 * Linux RedHat 3/x86_64: test-utimens (test-utimens.h:101: assertion failed) * Linux RedHat 4/x86: test-nanosleep (test-nanosleep.c:78: assertion failed) * Linux RedHat 4/x86: test-sleep (test-sleep.c:53: assertion failed) Thanks for the report. Can you repeat the tests with the very latest snapshot? http://meyering.net/cu/coreutils-ss.tar.gz 9.4 MB http://meyering.net/cu/coreutils-ss.tar.xz 4.0 MB If any of those failures persist, we *might* have time to address one or two before coreutils-8.4, which is slated to be released today. I think we may be encountering shell issues here? We get 127 rather than 129 under dash once the "hangup" message is displayed before `wait` is called $ /bin/sleep 20 & bg=$! $ kill -HUP $bg [1] + Hangup /bin/sleep 20 $ wait $bg $ echo $? 127
Re: coreutils-8.3: a few tests fail
Christophe LYON wrote: > I have built coreutils-8.3 and ran 'make check' on a few systems and I > have noticed some FAILs as follows. Given their old age, I am not sure > it is worth reporting, though. > > * Linux RedHat 3/x86: tail-2/inotify-hash-abuse, log extract: > + kill -HUP 15829 > [1]+ Hangup tail $debug -qF $(seq $n) >out 2>&1 > + wait 15829 > ./tail-2/inotify-hash-abuse: line 59: wait: pid 15829 is not a child > of this shell > + st=127 > + echo tail died via unexpected signal: 127 > tail died via unexpected signal: 127 > + fail=1 > > * Linux RedHat 3/x86: tail-2/inotify-hash-abuse2, log extract: > + kill -HUP 16044 > ./tail-2/inotify-hash-abuse2: line 40: kill: (16044) - No such process > + wait 16044 > + st=124 > + echo tail died via unexpected signal: 124 > tail died via unexpected signal: 124 > + fail=1 > > * Linux RedHat 3/x86_64: test-utimens (test-utimens.h:101: assertion failed) > > * Linux RedHat 4/x86: test-nanosleep (test-nanosleep.c:78: assertion failed) > * Linux RedHat 4/x86: test-sleep (test-sleep.c:53: assertion failed) Thanks for the report. Can you repeat the tests with the very latest snapshot? http://meyering.net/cu/coreutils-ss.tar.gz 9.4 MB http://meyering.net/cu/coreutils-ss.tar.xz 4.0 MB If any of those failures persist, we *might* have time to address one or two before coreutils-8.4, which is slated to be released today.
openbsd5.4: spurious ls/infloop test failure: due to bug in /bin/sh
Nelson Beebe build coreutils-8.3 on OpenBSD4.5 and reported this: FAIL: ls/infloop (exit: 1) Investigating, I found that openbsd4.5's sh has a bug that makes it malfunction like this: $ sh -c 'set -x; (echo s; echo e 1>&2) 2>err >/dev/null'; cat err + 2> err + > /dev/null + echo s + echo e + >&2 e Contrast with bash: $ bash -c 'set -x; (echo s; echo e 1>&2) 2>err >/dev/null'; cat err + echo s + echo e e Here's the fix: >From f28c7d959be30be0b216880878e8b0909d810a18 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 13 Jan 2010 10:53:32 +0100 Subject: [PATCH] tests: work around spurious test failure with OpenBSD4.5's /bin/sh * tests/ls/infloop: OpenBSD4.5's /bin/sh would mistakenly include "set -x"-output in an application's stderr stream when stderr is redirected before stdout. This was causing one spurious test failure. The work-around: redirect stdout first. Reported by Nelson Beebe. --- tests/ls/infloop |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/tests/ls/infloop b/tests/ls/infloop index 7d19b13..2ab486d 100755 --- a/tests/ls/infloop +++ b/tests/ls/infloop @@ -36,8 +36,7 @@ cat <<\EOF > exp-err || framework_failure ls: loop/sub: not listing already-listed directory EOF - -timeout 1 ls -RL loop 2>err > out +timeout 1 ls -RL loop >out 2>err # Ensure that ls exits with status 2 upon detecting a cycle test $? = 2 || fail=1 -- 1.6.6.511.gf46c4
[PATCH] tests: don't silently skip the sort-version tests
Surprise! We've been silently skipping the sort --version-sort (-V) tests. The behavior of bash via /bin/sh (same for zsh and dash, though without the warning) is probably POSIX-conforming, but this example illustrates why it would be better to emulate openBSD's /bin/sh. This will be in 8.4; if sort -V doesn't work, we want to know. >From 3b498ba1410d9730782db439db27e85ff20d0e56 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 13 Jan 2010 10:19:58 +0100 Subject: [PATCH] tests: don't silently skip the sort-version tests * tests/misc/sort-version: Don't use <<- and indented here-doc contents. s/<<-/<[4]: here document `x' unclosed [Exit 1] by contrast, bash warns but still exits successfully: $ printf 'cat<<-x\n foo\n x\n'|bash && echo you lose bash: line 3: warning: here-document at line 1 delimited by \ end-of-file (wanted `x') foo x you lose --- tests/misc/sort-version | 160 +++--- 1 files changed, 80 insertions(+), 80 deletions(-) diff --git a/tests/misc/sort-version b/tests/misc/sort-version index d80ea7b..741ee8b 100755 --- a/tests/misc/sort-version +++ b/tests/misc/sort-version @@ -23,87 +23,87 @@ fi . $srcdir/test-lib.sh -cat > in <<- _EOF_ -gcc-c++-10.fc9.tar.gz -gcc-c++-10.8.12-0.7rc2.fc9.tar.bz2 -glibc-2-0.1.beta1.fc10.rpm -glibc-common-5-0.2.beta2.fc9.ebuild -glibc-common-5-0.2b.deb -glibc-common-11b.ebuild -glibc-common-11-0.6rc2.ebuild -libstdc++-0.5.8.11-0.7rc2.fc10.tar.gz -libstdc++-4a.fc8.tar.gz -libstdc++-4.10.4.20040204svn.rpm -libstdc++-devel-3.fc8.ebuild -libstdc++-devel-3a.fc9.tar.gz -libstdc++-devel-8.fc8.deb -libstdc++-devel-8.6.2-0.4b.fc8 -nss_ldap-1-0.2b.fc9.tar.bz2 -nss_ldap-1-0.6rc2.fc8.tar.gz -nss_ldap-1.0-0.1a.tar.gz -nss_ldap-10beta1.fc8.tar.gz -nss_ldap-10.11.8.6.20040204cvs.fc10.ebuild -string start 5.0.0 end of str -string start 5.1.0 end of str -string start 5.10.0 end of str -string start 5.2.0 end of str -string start 5.20.0 end of str -string start 5.3.0 end of str -string start 5.30.0 end of str -string start 5.4.0 end of str -string start 5.40.0 end of str -string start 5.5.0 end of str -string start 5.50.0 end of str -string start 5.6.0 end of str -string start 5.60.0 end of str -string start 5.7.0 end of str -string start 5.70.0 end of str -string start 5.8.0 end of str -string start 5.80.0 end of str -string start 5.9.0 end of str -string start 5.90.0 end of str -_EOF_ +cat > in << _EOF_ +gcc-c++-10.fc9.tar.gz +gcc-c++-10.8.12-0.7rc2.fc9.tar.bz2 +glibc-2-0.1.beta1.fc10.rpm +glibc-common-5-0.2.beta2.fc9.ebuild +glibc-common-5-0.2b.deb +glibc-common-11b.ebuild +glibc-common-11-0.6rc2.ebuild +libstdc++-0.5.8.11-0.7rc2.fc10.tar.gz +libstdc++-4a.fc8.tar.gz +libstdc++-4.10.4.20040204svn.rpm +libstdc++-devel-3.fc8.ebuild +libstdc++-devel-3a.fc9.tar.gz +libstdc++-devel-8.fc8.deb +libstdc++-devel-8.6.2-0.4b.fc8 +nss_ldap-1-0.2b.fc9.tar.bz2 +nss_ldap-1-0.6rc2.fc8.tar.gz +nss_ldap-1.0-0.1a.tar.gz +nss_ldap-10beta1.fc8.tar.gz +nss_ldap-10.11.8.6.20040204cvs.fc10.ebuild +string start 5.0.0 end of str +string start 5.1.0 end of str +string start 5.10.0 end of str +string start 5.2.0 end of str +string start 5.20.0 end of str +string start 5.3.0 end of str +string start 5.30.0 end of str +string start 5.4.0 end of str +string start 5.40.0 end of str +string start 5.5.0 end of str +string start 5.50.0 end of str +string start 5.6.0 end of str +string start 5.60.0 end of str +string start 5.7.0 end of str +string start 5.70.0 end of str +string start 5.8.0 end of str +string start 5.80.0 end of str +string start 5.9.0 end of str +string start 5.90.0 end of str +_EOF_ -cat > exp <<- _EOF_ -gcc-c++-10.fc9.tar.gz -gcc-c++-10.8.12-0.7rc2.fc9.tar.bz2 -glibc-2-0.1.beta1.fc10.rpm -glibc-common-5-0.2.beta2.fc9.ebuild -glibc-common-5-0.2b.deb -glibc-common-11b.ebuild -glibc-common-11-0.6rc2.ebuild -libstdc++-0.5.8.11-0.7rc2.fc10.tar.gz -libstdc++-4a.fc8.tar.gz -libstdc++-4.10.4.20040204svn.rpm -libstdc++-devel-3.fc8.ebuild -libstdc++-devel-3a.fc9.tar.gz -libstdc++-devel-8.fc8.deb -libstdc++-devel-8.6.2-0.4b.fc8 -nss_ldap-1-0.2b.fc9.tar.bz2 -nss_ldap-1-0.6rc2.fc8.tar.gz -nss_ldap-1.0-0.1a.tar.gz -nss_ldap-10beta1.fc8.tar.gz -nss_ldap-10.11.8.6.20040204cvs.fc10.ebuild -string start 5.0.0 end of str -string start 5.1.0 end of str -string start 5.2.0 end of str -string start 5.3.0 end of str -string start 5.4.0 end of str -string start 5.5.0 end of str -string start 5.6.0 end of str -string start 5.7.0
