Re: dd interface to posix_fadvise
Paul Eggert wrote: Pádraig Brady [EMAIL PROTECTED] writes: I was thinking it would be useful to add an option to dd to tell it to instruct the OS not to cache the data. Yes, that's handy, but doesn't dd iflag=direct already do that for you? Not exactly. That bypasses all the kernelly goodness. For example if the file is already cached you needlessly read from disk. Also readahead for performance is also not done. Hmm, I see that Linus doesn't like O_DIRECT http://kerneltrap.org/node/7563. Perhaps we should also support the method that Linus prefers. Can you fill us in as to why that is? I didn't know about linus' views on O_DIRECT. They match mine though, so they're definitely right :) Note, posix_fadvise(POSIX_FADV_DONTNEED) on linux, invalidates the cache for a file rather than a process This is not what is usually required, and I'm working on the kernel guys to get them to change this. Yes, thanks, that sounds right. FYI, I'm thinking one can achieve this by just invalidating pages that have a reference count of 1. But dd always accesses the file sequentially. Wouldn't POSIX_FADV_SEQUENTIAL be better? or perhaps POSIX_FADV_NOREUSE? And if not, why not? They might be good to set, but probably not: http://lxr.linux.no/source/mm/fadvise.c http://www.die.net/doc/linux/man/man2/posix_fadvise.2.html I just tried the following naive patch on my Debian stable host and dd immediately dumped core inside posix_fadvise. This is not a good sign. It sounds like, despite Linus's wishes, posix_fadvise is not really ready for prime_time. diff --git a/src/dd.c b/src/dd.c + posix_fadvise (STDIN_FILENO, 0, 0, POSIX_FADV_SEQUENTIAL); + posix_fadvise (STDOUT_FILENO, 0, 0, POSIX_FADV_SEQUENTIAL); That's mad. That trival patch works fine here on coreutils-6.2 + glibc-2.3.5-10 + 2.6.16-1.2111_FC4 at least. Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -r sometimes produces errors under NFS
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: When an NFS client sees a successful unlink, it is reasonable to expect a client-side rewinddir/readdir sequence *not* to produce the just-unlinked name. I agree, but won't this hurt rewinddir performance? After all, one of Won't *what* hurt rewinddir performance? The test for whether to call rewinddir is only performed upon reaching end of directory (readdir returns NULL with errno == 0). The rewinddir call is then performed only when n_unlinked_since_opendir_or_last_rewind is at least as large as CONSECUTIVE_READDIR_UNLINK_THRESHOLD. The cost of calling rewinddir (and rereading any . and .. entries) once per directory-containing-CONSECUTIVE_READDIR_UNLINK_THRESHOLD-or-more entries seems small. I think I measured it back when I lowered its value to 10. Just in case, I've timed it again, using what should be a worst-case scenario: a hierarchy with branching factor of 11. This example has 11^5 leaf directories. No files. on a tmpfs file system. All names have /t/z/ prefix. Here are examples: /t/z/0/0/0/1/0 /t/z/0/0/0/0/10 /t/z/0/0/0/0/9 /t/z/0/0/0/0/8 /t/z/0/0/0/0/7 /t/z/0/0/0/0/6 /t/z/0/0/0/0/5 /t/z/0/0/0/0/4 /t/z/0/0/0/0/3 /t/z/0/0/0/0/2 /t/z/0/0/0/0/1 /t/z/0/0/0/0/0 Removing such a hierarchy on an AMD-64/3400+ and linux-2.6.18-3-amd64 with GNU rm (6.8+) averages around ~6.1 seconds on a mostly idle system. However, there is so much deviation (sometimes over 1s) in those timings that there is no hope of seeing any difference when NEED_REWIND is 0. Even ignoring the worst deviations, if there is a difference, it is immeasurable. Then I realized that the above, being a tree of all directories, wasn't a good test at all. The rewinddir code is not relevant, since the number of consecutive_readdirs_... never exceeds the threshold. So I redid it with the leaves as files. With that scenario, rm runs much faster so it can remove a 10^6-leaf tree in a reasonable amount of time, (once I made sure there was 1GB free on the target file system :-) so I adjusted CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 9, and reran: Here's stock rm with the above change: $ for i in $(seq 10); do z-mktree --root=/t/z --b=10 --d=6; /usr/bin/time /cu/src/rm -rf /t/z; done 1.11user 9.82system 0:11.08elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.00user 8.59system 0:09.63elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 0.99user 8.99system 0:11.96elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.15user 8.75system 0:11.48elapsed 86%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+167minor)pagefaults 0swaps 1.28user 8.39system 0:09.68elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.00user 8.80system 0:09.90elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.05user 8.94system 0:10.15elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.14user 9.42system 0:10.58elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.14user 8.70system 0:09.89elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 0.88user 9.63system 0:12.05elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps Here's the same test, but with stock rm having NEED_REWIND == 0: i.e., no extra rewinddir or readdir calls: 0.93user 8.62system 0:09.85elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 0.92user 8.63system 0:09.66elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.08user 9.50system 0:11.35elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+167minor)pagefaults 0swaps 1.08user 9.15system 0:10.68elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+167minor)pagefaults 0swaps 0.99user 9.28system 0:10.28elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+167minor)pagefaults 0swaps 1.14user 7.96system 0:09.53elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.02user 9.05system 0:10.10elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 1.04user 8.35system 0:09.40elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+166minor)pagefaults 0swaps 0.98user 8.40system 0:09.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+167minor)pagefaults 0swaps 1.14user 8.76system 0:09.91elapsed 99%CPU (0avgtext+0avgdata
Re: dd conv=nocache
Pádraig Brady [EMAIL PROTECTED] wrote: I was thinking it would be useful to add an option to dd to tell it to instruct the OS not to cache the data. I like the idea, even if it works only with very recent Linux kernels. Personally I use dd to move large files like disc images etc. around, and I know I will not need the file cached. A very quick example patch which has only been tested on linux is attached. Do you think this is required? Do you think this is the right interface? There are two separate sets of data to which we might want to apply such an optimization: input and output. So how about an interface that lets the user disable caching on either or both? E.g., no-i-cache no-o-cache. I find the --less options far less readable. Actually, I prefer the even longer names: input-cache-disable output-cache-disable nocache could still be an alias for the combination. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd conv=nocache
Jim Meyering wrote: Pádraig Brady [EMAIL PROTECTED] wrote: I was thinking it would be useful to add an option to dd to tell it to instruct the OS not to cache the data. I like the idea, even if it works only with very recent Linux kernels. It's not that new. It's in since 2.5.60 according to the man page, and I verified the code is in 2.6.0 Also it uses a posix interface, so I presume this is available elsewhere. Personally I use dd to move large files like disc images etc. around, and I know I will not need the file cached. A very quick example patch which has only been tested on linux is attached. Do you think this is required? Do you think this is the right interface? There are two separate sets of data to which we might want to apply such an optimization: input and output. So how about an interface that lets the user disable caching on either or both? E.g., no-i-cache no-o-cache. I find the --less options far less readable. Actually, I prefer the even longer names: input-cache-disable output-cache-disable nocache could still be an alias for the combination. I considered this, but thought you wouldn't need this granularity. But thinking more about it I think you're right. If we want to control input and output separately perhaps we should use flags. So we have: iflag=nocache and oflag=nocache The usual case where we want to do the same on both could be handled with flag=nocache One can't specify both [io]flag=FLAGS with flag=FLAGS at present, but I think that should be supported anyway. thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd conv=nocache
Pádraig Brady [EMAIL PROTECTED] wrote: Jim Meyering wrote: Pádraig Brady [EMAIL PROTECTED] wrote: I was thinking it would be useful to add an option to dd to tell it to instruct the OS not to cache the data. I like the idea, even if it works only with very recent Linux kernels. It's not that new. It's in since 2.5.60 according to the man page, and I verified the code is in 2.6.0 Also it uses a posix interface, so I presume this is available elsewhere. Note that I said works, not exists :-) Does it work consistently even for initial versions? ... I considered this, but thought you wouldn't need this granularity. But thinking more about it I think you're right. If we want to control input and output separately perhaps we should use flags. So we have: iflag=nocache and oflag=nocache Of course! Using that mechanism is the way to go. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd interface to posix_fadvise
Pádraig Brady [EMAIL PROTECTED] writes: http://www.die.net/doc/linux/man/man2/posix_fadvise.2.html Wow. That makes it seem like POSIX_FADV_SEQUENTIAL isn't nearly as useful as it should be. What I think you're saying is that applications must invoke POSIX_FADV_DONTNEED by hand after reading or writing every sequential page. But this is what POSIX_FADV_SEQUENTIAL is designed for, no? That is, POSIX_FADV_SEQUENTIAL should be tuned for usage patterns like dd's, right? Why isn't it? (Now I'm starting to understand why almost nobody uses posix_fadvise. :-) + posix_fadvise (STDIN_FILENO, 0, 0, POSIX_FADV_SEQUENTIAL); + posix_fadvise (STDOUT_FILENO, 0, 0, POSIX_FADV_SEQUENTIAL); That's mad. That trival patch works fine here on coreutils-6.2 + glibc-2.3.5-10 + 2.6.16-1.2111_FC4 at least. It sounds like we'll have to have a fairly-careful runtime test then, with the default being not to use posix_fadvise unless we're sure it won't dump core. Debian stable is not a platform I'd like to abandon quite just yet One option I toyed with is giving users direct access to the posix_fadvise parameters, so they can set the options themselves, and get core dumps on their own. E.g., dd iadvice=sequential oadvice=sequential This is sort of like iflags and oflags, but for posix_fadvice. It matches the POSIX spec fairly well, though it is a bit overkill (would 'dd' really have any use for iadvice=random? :-). But the problem is that it doesn't match Linux's somewhat odd interpretation of posix_fadvise very well. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -d YYYYMMDD.HHMM
[EMAIL PROTECTED] (Karl Berry) writes: Would it hard for date -d to accept MMDD.HHMM as well as MMDD HHMM? I often use the period, since then it's a number that can at least be compared ... It could be done, but it wouldn't be trivial, as the lexer currently treats MMDD.HHMM as a count of seconds to the nearest 10,000th of a second. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Sort: buffer-size bug and nmerge performance issue
William Herrin [EMAIL PROTECTED] writes: 1. sort running on Linux kernel 2.6 x86_64 will accept but mishandle a --buffer-size argument larger than 2048M. It will silently pick some size noticeably smaller than 2048M. This is on a 64-bit machine with no ulimits on the amount of memory a process can consume. First, you need to compile coreutils in 64-bit mode to be able to use 64-bit sizes. (The default is to compile in 32-bit mode.) I assume you've done that? If not, please try that. Second, 'sort' is at the mercy of your malloc implementation. That is, 'sort' tries to malloc 2048M, and if that fails, it tries a smaller allocation. The idea is that it's better to get to sort done than to complain about running out of memory. Perhaps your C library doesn't let 'malloc' succeed with large values? You can test this by writing a little test program. Has anyone done any testing to see if 16 is an optimal number for the merge size? It depends on the platform. It might well make sense to revisit that number, or even make it a user option with a more-reasonable default. Have you tried using compression on temporaries (the new --compress-program option in coreutils 6.8)? That probably affects the optimal number. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -d YYYYMMDD.HHMM
treats MMDD.HHMM as a count of seconds to the nearest 10,000th of It does? $ date -d 20070307.1010 date: invalid date `20070307.1010' coreutils 6.7. This error message is the reason I felt it was worth taking up your time with at all; if it already had/has an alternative interpretation, then it's certainly not worth dealing with. Thanks, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -r sometimes produces errors under NFS
Jim Meyering [EMAIL PROTECTED] writes: Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: When an NFS client sees a successful unlink, it is reasonable to expect a client-side rewinddir/readdir sequence *not* to produce the just-unlinked name. I agree, but won't this hurt rewinddir performance? After all, one of Won't *what* hurt rewinddir performance? I don't know the NFS details, but my assumption is that an obvious fix for this bug would have the NFS client invalidate its cache of directory entries after an unlink/rewinddir sequence. Hence the client would have to go back to the server on the next readdir (or maybe stat), and that's another server round trip we'd like to avoid. There might be better fixes but they'd require more memory on the client. (This is just a guess of course! I haven't measured it. I don't use NFS under Linux.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -r sometimes produces errors under NFS
Vincent Lefevre [EMAIL PROTECTED] wrote: On 2007-03-07 01:13:11 +0100, Jim Meyering wrote: You want to ignore only certain ENOENT errors. With the current implementation, knowing which to ignore would require recording which names have been successfully unlinked. In fact I want to ignore all ENOENT errors, but you disagreed. Wrong. In the recurse phase, if rm tries to unlink a file, this means that the file has existed. So, this wouldn't be contrary to POSIX. Your conclusion is invalid. What if some other process removed it first? AFAIK, POSIX doesn't say that there should be an error in this particular case, Yes, it does. This part of the standard is clear: If this fails for any reason ... This is not a failure: rm has seen the file and the file has been removed. If you want to discuss further whether rm -r should ignore ENOENT unconditionally, I suggest that you raise the issue with the people who work on the POSIX standard (use the austin-group-l mailing list; subscribe at http://www.opengroup.org/austin/lists.html). If you can convince them that you're right, then you'll have a much easier time convincing me to change the corresponding bits in coreutils. and IMHO, it is better and more consistent *not* to return an error. Indeed, consider the following case: Doing that would be inconsistent with other implementations, too. Do the other implementations do rewinddir too? You can check, but it's not relevant. This is independent of the rewinddir vs. NFS issue. Try to imagine why -f has the ENOENT-ignoring semantics. 1. rm -r dir is started. 2. A second process removes some file in some subdirectory of dir, and the rm -r process hasn't had the time to see it. 3. rm -r terminates (without any error). Why would you want rm -r to return an error if some file is removed by a second process between the time rm -r does the readdir and the time unlink is performed on this file by rm -r, but have no errors in the case I've described above? To know that your rm was competing with another file-removing process. Except in particular cases, one can't know that with the current rm implementation. So, this is not a valid reason. To conform with POSIX. This is a point on which I disagree. If you have more POSIX interpretation questions, please take it up with the austin-group-l list. To be consistent with all other rm implementations. See the above question about rewinddir. As I said above, this is independent of rewinddir. coreutils' rm -r will never be changed to ignore ENOENT unconditionally. Also note that in the NFS case, the errors are due to the rewind, but Point 2c for rm in POSIX is[*]: For each entry contained in file, other than dot or dot-dot, the four steps listed here (1 to 4) shall be taken with the entry as if it were a file operand. The rm utility shall not traverse directories by following symbolic links into other parts of the hierarchy, but shall remove the links themselves. [*] http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html (I don't know if this is the latest version...) So, if you want a strict interpretation of For each entry, I don't think a rewind is allowed. We've come full circle (maybe twice :-). It comes down to having consistent results from unlink and readdir. When readdir returns NULL with no error, I can safely call rewinddir and then use readdir to iterate through any new entries. But POSIX just says For each entry contained in file. It doesn't say While there is an entry in file. With rewinddir, you're doing While there is an entry in file, and rm -r can loop indefinitely (depending on the other processes). Precisely. That is how I chose (and choose) to implement rm. Certainly, there are contrived scenarios in which GNU rm will not terminate (you'd need multiple concurrent processes creating entries in a directory that rm is removing, since unlinking is faster than creation) but one can also argue that rm is doing what the user wants in that case. If you'd like to continue with this topic, please take it up with the Austin Group mailing list. Your system violates that assumption. NFS violates many things. If any unlink fails, rm does not try to call rmdir on any parent directory. If your case (all unlinks failed with ENOENT) were common, it might be worth handling it by attempting the rmdir if that's the only type of failure. There is another case. Say, you have two shells 1 and 2: 1 mkdir dir 1 touch dir/a 1 touch dir/b 1 rm -ri dir rm: descend into directory `dir'? y rm: remove regular empty file `dir/a'? n rm: remove regular empty file `dir/b'? Before answering, in the second shell: 2 rm dir/a Then back to the first shell: rm: remove regular empty file `dir/b'? y 1 test -d dir echo OK OK IMHO, this is incorrect. Step 4 just says: If the current file is a directory, rm shall perform actions equivalent
bootstrap: making it slightly more general
FYI,
This change is useful in a project that does not have a need for its
own build-aux directory. I.e., it uses it build-aux/, yet maintains
nothing version-controlled therein. So it needn't exist initially
and ./bootstrap creates it if needed.
diff --git a/ChangeLog b/ChangeLog
index 9bec73d..73e03d0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2007-03-08 Jim Meyering [EMAIL PROTECTED]
+
+ Make bootstrap a little more general.
+ * bootstrap (build_aux): Factor out/use this definition.
+ Formally require a AC_CONFIG_AUX_DIR($build_aux) line in configure.ac.
+ (insert_sorted_if_absent): Move function definition up, to
+ precede new first use.
+ If $build_aux/ doesn't exist initially, create it, and
+ mark it as ignored.
+
2007-03-03 Andrew Church [EMAIL PROTECTED] (tiny change)
Paul Eggert [EMAIL PROTECTED]
diff --git a/bootstrap b/bootstrap
index bf94f9b..887ec53 100755
--- a/bootstrap
+++ b/bootstrap
@@ -90,17 +90,18 @@ extract_package_name='
'
package=`sed -n $extract_package_name configure.ac` || exit
+build_aux=build-aux
# Extra files from gnulib, which override files from other sources.
-gnulib_extra_files='
- build-aux/install-sh
- build-aux/missing
- build-aux/mdate-sh
- build-aux/texinfo.tex
- build-aux/depcomp
- build-aux/config.guess
- build-aux/config.sub
+gnulib_extra_files=
+ $build_aux/install-sh
+ $build_aux/missing
+ $build_aux/mdate-sh
+ $build_aux/texinfo.tex
+ $build_aux/depcomp
+ $build_aux/config.guess
+ $build_aux/config.sub
doc/INSTALL
-'
+
# Other locale categories that need message catalogs.
EXTRA_LOCALE_CATEGORIES=
@@ -156,6 +157,32 @@ if test -n $CVS_only_file test ! -r $CVS_only_file;
then
exit 1
fi
+# If $STR is not already on a line by itself in $FILE, insert it,
+# sorting the new contents of the file and replacing $FILE with the result.
+insert_sorted_if_absent() {
+ file=$1
+ str=$2
+ echo $str | sort -u - $file | cmp -s - $file \
+|| echo $str | sort -u - $file -o $file \
+|| exit 1
+}
+
+# Die if there is no AC_CONFIG_AUX_DIR($build_aux) line in configure.ac.
+grep '^[]*AC_CONFIG_AUX_DIR('$build_aux')' configure.ac /dev/null ||
+ {
+echo $0: expected line not found in configure.ac. Add the following: 2
+echo AC_CONFIG_AUX_DIR($build_aux) 2.
+ }
+
+# If $build_aux doesn't exist, create it now, otherwise some bits
+# below will malfunction. If creating it, also mark it as ignored.
+if test ! -d $build_aux; then
+ mkdir $build_aux
+ for ig in .cvsignore .gitignore; do
+test -f $ig insert_sorted_if_absent $ig $build_aux
+ done
+fi
+
echo $0: Bootstrapping CVS $package...
cleanup_gnulib() {
@@ -358,16 +385,6 @@ version_controlled_file() {
test $found = yes
}
-# If $STR is not already on a line by itself in $FILE, insert it,
-# sorting the new contents of the file and replacing $FILE with the result.
-insert_sorted_if_absent() {
- file=$1
- str=$2
- echo $str | sort -u - $file | cmp -s - $file \
-|| echo $str | sort -u - $file -o $file \
-|| exit
-}
-
slurp() {
for dir in . `(cd $1 find * -type d -print)`; do
copied=
@@ -431,7 +448,7 @@ mkdir $bt $bt2 || exit
gnulib_tool_options=\
--import\
--no-changelog\
- --aux-dir $bt/build-aux\
+ --aux-dir $bt/$build_aux\
--doc-base $bt/doc\
--lib lib$package\
--m4-base $bt/m4/\
--
1.5.0.2.279.g4808
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
bootstrap: Run libtool, if necessary.
Just committed: * bootstrap: Run libtool, if necessary. diff --git a/bootstrap b/bootstrap index 887ec53..dde3e21 100755 --- a/bootstrap +++ b/bootstrap @@ -478,11 +478,17 @@ rm -fr $bt $bt2 || exit # Reconfigure, getting other files. for command in \ + libtool \ 'aclocal --force -I m4' \ 'autoconf --force' \ 'autoheader --force' \ 'automake --add-missing --copy --force-missing'; do + if test $command = libtool; then +grep '^[]*AM_PROG_LIBTOOL\' configure.ac /dev/null || + continue +command='libtoolize -c -f' + fi echo $0: $command ... $command || exit done ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: stty discard undef fails under Mac OS X
Hi, Any news? On 2007-02-14 19:43:09 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: Under Mac OS X: prunille:~ /usr/local/bin/stty --version stty (GNU coreutils) 6.7 [...] prunille:~ /usr/local/bin/stty discard undef /usr/local/bin/stty: invalid argument `discard' Try `/usr/local/bin/stty --help' for more information. zsh: exit 1 /usr/local/bin/stty discard undef But with the stty provided by Mac OS X, /bin/stty discard undef works as expected: prunille% /bin/stty -a | grep discard cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; prunille% /bin/stty discard undef prunille% /bin/stty -a | grep discard cchars: discard = undef; dsusp = ^Y; eof = ^D; eol = undef; It seems that stty flush undef does the same thing and works with the coreutils, but it isn't described in the coreutils stty(1) man page and in the stty --help output: prunille:~ /usr/local/bin/stty --help | grep flush * dsusp CHARCHAR will send a terminal stop signal once input flushed * [-]imaxbelbeep and do not flush a full input buffer on a character [-]noflsh disable flushing after interrupt and quit special characters Thanks for the report. I hesitate to document flush, but might add an alias discard, and perhaps stflush, since the latter is what Solaris 10 calls it. I'm inclined not to document flush since it's not specified by POSIX, and people might think it is the opposite of noflsh. If someone does a survey of what other vendor-provided versions of stty do (and summarizes here), that might accelerate the process. If you don't hear back in a couple weeks, please ping the list. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
