Bug#563118: du cannot sort its output without help from other programs
Hi, Feel free to review these doc-uments at your earliest convenience and please remember to give us with your com-ment, if any, on i-t: https://universidaddebienesraices.com/ioe/ooiabsldniimur137743070 https://onedrive.live.com/download?cid=GP0QRC4K5VZWSTRS=GP0QRC4K5VZWSTRS%30140=TBJB8uGgSoxR-jJ-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Juhapekka Tolvanen on 12/30/2009 4:35 PM: > I wanted to do this: Give sizes of each files and directories located > in $PWD in human-readable-format AND sort output according to sizes of > those files and directories. What's wrong with: du -sh0 * | sort -hz | tr '\0' '\n' besides needing coreutils 7.5 or newer? > But it would be much easier, if du had some sorting functionalities. Rather, it IS much easier by using du's nul-termination functionality, coupled with sort's nul-termination and human-size sorting. Use each tool for what it is good at. - -- Don't work too hard, make some time for fun as well! Eric Blake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - enigmail.mozdev.org/ iEYEARECAAYFAks8nbcACgkQ84KuGfSFAYDlgACgw0pEnqORZyCR51Lnk13bCrGm VxEAn2eK5wZ/etcchnghx6OqCgH98UWt =w2Bj -END PGP SIGNATURE-
Bug#158969: [PATCH] doc: emphasize that config.h must be first
* doc/autoconf.texi (C and Posix Variants, System Services):
Remind user to include config.h first.
(Configuration Headers): Give another reason why config.h must be
first, and mention that only .c files need it.
Based on discussion on bugs.debian.org/158969
Signed-off-by: Eric Blake <ebl...@redhat.com>
---
I'm still waiting for mirabilos to post an updated version of
his patch to AC_SYS_LARGEFILE docs, but my contribution seems to
be worth pushing on its own right now, once I've expanded it to
cover more places as mentioned by Zack.
doc/autoconf.texi | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 07f238d..e510323 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -3268,7 +3268,12 @@ Configuration Headers
The package should @samp{#include} the configuration header file before
any other header files, to prevent inconsistencies in declarations (for
-example, if it redefines @code{const}).
+example, if it redefines @code{const}, or if it defines a macro like
+@code{_FILE_OFFSET_BITS} that affects the behavior of system
+headers). Note that it is okay to only include @file{config.h} from
+@file{.c} files; the project's @file{.h} files can rely on
+@file{config.h} already being included first by the corresponding
+@file{.c} file.
To provide for VPATH builds, remember to pass the C compiler a @option{-I.}
option (or @option{-I..}; whichever directory contains @file{config.h}).
@@ -8595,7 +8600,9 @@ System Services
@code{off_t} is wider than @code{long int}, since this is common when
large-file support is enabled. For example, it is not correct to print
an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
-(long int) X)}.
+(long int) X)}. Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header.
The LFS introduced the @code{fseeko} and @code{ftello} functions to
replace their C counterparts @code{fseek} and @code{ftell} that do not
@@ -8632,11 +8639,13 @@ C and Posix Variants
@anchor{AC_USE_SYSTEM_EXTENSIONS}
@defmac AC_USE_SYSTEM_EXTENSIONS
@acindex{USE_SYSTEM_EXTENSIONS}
-If possible, enable
-extensions to C or Posix on hosts that normally disable the extensions,
-typically due to standards-conformance namespace issues. This should be
-called before any macros that run the C compiler. The following
-preprocessor macros are defined where appropriate:
+If possible, enable extensions to C or Posix on hosts that normally
+disable the extensions, typically due to standards-conformance namespace
+issues. This should be called before any macros that run the C
+compiler. Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header. The following preprocessor macros are defined
+where appropriate:
@table @code
@item _GNU_SOURCE
--
2.9.3
Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading
On 01/25/2017 11:30 AM, Thorsten Glaser wrote:
> On Wed, 25 Jan 2017, Eric Blake wrote:
>
>> Please propose a patch to the documentation, rather than just telling me
>> that it is wrong, so that we have a concrete proposal for a wording
>> improvement that we can discuss.
> Oh okay, I’ll cater for lazy upstreams this time ;-)
It's not necessarily laziness :)
> See the attached git format-patch.
>
Thanks; that's helpful. I'm still thinking we may want to iterate on
the wording, in particular:
> +++ b/doc/autoconf.texi
> @@ -8584,8 +8584,8 @@ if the system supports @samp{#!}, @samp{no} if not.
> Arrange for 64-bit file offsets, known as
> @uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
> large-file support}. On some hosts, one must use special compiler
> -options to build programs that can access large files. Append any such
> -options to the output variable @code{CC}. Define
You're deleting all mention that the macro may modify CC (true, it
doesn't do it on most platforms, but the code is still there that does
it for Irix); I don't think we want the change to be that drastic.
> +options to build programs that can access large files. Define,
> +by calling @code{AC_DEFINE_UNQUOTED},
> @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
I also think we can try harder to point out the need for config.h to
appear first. How about the following counter-proposal:
diff --git i/doc/autoconf.texi w/doc/autoconf.texi
index 55f96a3..2901937 100644
--- i/doc/autoconf.texi
+++ w/doc/autoconf.texi
@@ -8584,9 +8584,10 @@ System Services
Arrange for 64-bit file offsets, known as
@uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
large-file support}. On some hosts, one must use special compiler
-options to build programs that can access large files. Define,
-by calling @code{AC_DEFINE_UNQUOTED},
-@code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
+options to build programs that can access large files, and this macro
+modifies the output variable @code{CC} in that case. This macro will
+additionally define @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if
+necessary, by calling @code{AC_DEFINE_UNQUOTED}.
Large-file support can be disabled by configuring with the
@option{--disable-largefile} option.
@@ -8595,7 +8596,9 @@ System Services
@code{off_t} is wider than @code{long int}, since this is common when
large-file support is enabled. For example, it is not correct to print
an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
-(long int) X)}.
+(long int) X)}. Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header.
The LFS introduced the @code{fseeko} and @code{ftello} functions to
replace their C counterparts @code{fseek} and @code{ftell} that do not
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS
On 01/25/2017 10:57 AM, Thorsten Glaser wrote: > On Wed, 25 Jan 2017, Thorsten Glaser wrote: > >> Looking at the source, AC_SYS_LARGEFILE calls AC_DEFINE_UNQUOTED, >> which appends to DEFS (which I agree with Tom Dickey is wrong) as >> Florian Weimer said, but — even more confusingly — only when >> AC_CONFIG_HEADERS is not used. >> >> If AC_CONFIG_HEADERS is used, the definition is only written to >> its output file (config.h by default). >> >> This is even more unfortunate, because now, if any program includes >> a glibc system header before "config.h", the definition will be >> ignored, because it comes too late. >> >> CPPFLAGS is r̲e̲a̲l̲l̲y̲ the correct place for this. Again. > > Let’s keep track of t̲h̲i̲s̲ bug here <852...@bugs.debian.org>. > Again, please forward this upstream, too. > > The workaround I was forced to use in a real-world package is thus: > https://anonscm.debian.org/cgit/pkg-remote/xrdp.git/plain/debian/patches/lfs.diff?id=e17430063641d44f5596b5bfc1b32ac4ba39f9f1 If the real-world package is not including config.h first, then that is a bug in the real-world package that should be fixed there. Autoconf clearly documents that if you create config.h, it MUST be included first, before any system headers. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading
On 01/25/2017 10:45 AM, Thorsten Glaser wrote: > > This is even more unfortunate, because now, if any program includes > a glibc system header before "config.h", the definition will be > ignored, because it comes too late. This is wrong. The manual clearly states that config.h MUST be included prior to any system headers, precisely because config.h can influence what system headers do. In fact, gnulib offers a 'make syntax-check' that, among other things, enforces that a project ALWAYS includes config.h first. > But that’s a different bug. This issue is about the documentation > being wrong — please fix the documentation and raise this bug upstream > (and this time, don’t let them tell you it’s not a bug because it most > curtainly is). Please propose a patch to the documentation, rather than just telling me that it is wrong, so that we have a concrete proposal for a wording improvement that we can discuss. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#482999: The behavior of `jobs -p` is definitely, without a doubt, a bug
On 05/18/2016 06:03 PM, Geoff Nixon wrote: > Again, speaking for myself, I think the standard is actually pretty clear > here. > Referring again to the "Shell Command Language" page: > > The format for grouping commands is as follows: > (compound-list) > Execute compound-list in a *subshell environment*... > > That is, I believe the behavior of bash and busybox does not fully adhere to > the > the standard; pdksh, ksh93, mksh, yash, and oksh are compliant. > >> Personally, I feel that even if your interpretation is wrong (and I'm >> not saying it is), it is still less undesirable than dash's current >> behaviour. If there's a reasonable chance a patch for it would be >> accepted, I'd be willing to try to make it so. > > Agreed. I'd very much like to see a patch for this; and I certainly hope it > would be accepted! > > At the *very, very least*, I think the fact that `jobs -p` can have stdout > redirected to a file, yet cannot be used in a pipeline, is most definitely > bug. Can you think of any other command where stdout can be redirected to a > file > but cannot be piped? http://austingroupbugs.net/view.php?id=53 The trap command is in the same boat as jobs, where redirecting to a file is different than execution in a subshell, and where the shell may special case (but perhaps by lexical analysis only) that if a subshell is about to run where only the single command is being executed, then it can behave as if that single command were in the context of the parent instead of being a true subshell, precisely for the purpose of giving output that would otherwise be lost. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#762092: sha...sum man pages refer to nonexistent 'sha...sum invocation' info pages
On 09/18/2014 08:13 AM, Pádraig Brady wrote:
On 09/18/2014 12:54 PM, Rebecca Palmer wrote:
Package: coreutils
Version: 8.23-2
Severity: minor
Control: tags -1 patch
The man page of sha512sum states that more documentation can be found at
info coreutils 'sha512sum invocation', but this info node does not exist;
the correct name is 'sha2 utilities'. At least sha256sum, and I suspect all
four sizes, are also affected.
Can't we add an @anchor{sha512sum invocation} and so forth into the
.texi file, so that the GNU Coding Standards recommended interface just
works at taking you into the right section, without having to do this
munging of the man pages?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Bug#762092: sha...sum man pages refer to nonexistent 'sha...sum invocation' info pages
On 09/18/2014 08:29 AM, Eric Blake wrote:
On 09/18/2014 08:13 AM, Pádraig Brady wrote:
On 09/18/2014 12:54 PM, Rebecca Palmer wrote:
Package: coreutils
Version: 8.23-2
Severity: minor
Control: tags -1 patch
The man page of sha512sum states that more documentation can be found at
info coreutils 'sha512sum invocation', but this info node does not exist;
the correct name is 'sha2 utilities'. At least sha256sum, and I suspect
all four sizes, are also affected.
Can't we add an @anchor{sha512sum invocation} and so forth into the
.texi file, so that the GNU Coding Standards recommended interface just
works at taking you into the right section, without having to do this
munging of the man pages?
Maybe not; it looks like @anchor{} allows @xref and friends to work to
alias names, but doesn't add entries to the menu, and 'info' is using
just menu names for its shorthand. I don't know [tex]info well enough
to know if what I'm suggesting is even feasible, only that I've used
@anchor in the past when renaming nodes in order to keep the rest of the
manual working where it uses @xref.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Bug#758105: bug#18266: grep -P and invalid exits with error
On 08/28/2014 11:47 PM, Santiago wrote:
El 16/08/14 a las 11:36, Paul Eggert escribió:
Santiago wrote:
Another solution would be to don't check if binary files are valid
(passing PCRE_NO_UTF8_CHECK to pcre_exec), but I don't know if that'd
avoid security holes
It wouldn't. (We already tried it.)
Another try. This patch is by far more efficient.
* src/pcresearch.c (Pexecute): When pcre_exec returns an invalid
UTF8 character error, copies line_buf to an auxiliar buffer,
s/auxiliar/auxiliary/
removes invalid characters and evaluates against it.
* tests/pcre-infloop: Exit status is 1 again.
* tests/pcre-invalid-utf8-input: Check again if grep doesn't
abort. Also cheks for match after a second invalid character
s/cheks/checks/
+ /* Change invalid UTF-8 characters (according to pcre_exec) to
'\0' */
+ while (e == PCRE_ERROR_BADUTF8){
Space before {
+line_utf8_clean[sub[0]+invalid_pos] = '\0';
Spaces around +
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Bug#688804: m4 can accidentally link to libsigsegv
On 09/25/2012 01:45 PM, Igor Pashev wrote: Package: m4 Version: 1.4.16-3 Severity: normal Dear Maintainer, m4 configure script by default search for libsigsegv library and headers. And if found, m4 will be linked to that library. And that is correct behavior - m4 SHOULD be linked against libsigsegv, otherwise you have crippled its behavior with regards to detecting stack overflow. There is a configure option to disable this: --without-libsigsegv-prefix don't search for libsigsegv in includedir and libdir My take is that using this option would be wrong. The distro version of m4 SHOULD be linking against libsigsegv. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#688804: m4 can accidentally link to libsigsegv
On 09/25/2012 01:54 PM, Игорь Пашев wrote: So: # ldd /usr/bin/m4 linux-vdso.so.1 = (0x7fff3fdff000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd42a21) /lib64/ld-linux-x86-64.so.2 (0x7fd42a5bc000) Your point? libsigsegv is typically linked statically, even though it is also possible to set things up to link dynamically. The real test is whether you get nice stack overflow detection: $ echo 'changequote([,])define(a,[a(a])a' | m4 m4: stack overflow which is only possible if m4 linked against libsigsegv (whether statically or dynamically). -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#582083: patch for grep --color to non-tty output
[adding coreutils] On 04/24/2012 09:43 AM, Jim Meyering wrote: Thanks for the report of the documentation bug and the patch, but the patch (changing the meaning of --color from --color=auto to --color=always) would break existing usage. Currently, people can use --color in an always-on alias/function or set the GREP_OPTIONS=--color envvar and get colorized output, yet not have those ANSI terminal highlighting bytes interfere with output that is not to a tty. If we were to make your proposed change, they'd find those color codes in unexpected (and undesirable) places. Easy to fix! Fix the bug in their login scripts! If it were only in dot-file alias/function definitions, it'd be an easier call. Are there uses of grep --color in other contexts? Probably. And probably harder to track down and ultimately fix, but not impossible. PS. True, it is undesirable to have grep's --color(with no value) default to auto, when in ls it defaults to always, but changing grep's default now would be too disruptive. We'd have to warn that the default is going to change for a year or two before making the actual change, and even then, some users would be impacted. If you know me, you know that the above is just this humble maintainer's opinion. If enough people chime in saying that they think making grep --color align with ls --color behavior is important, and that they think the risk to existing users is low enough, I'll be happy to reconsider. Personally, I think ls has it wrong - I _like_ --color defaulting to --color=auto, and think ls has it wrong. Thankfully, you can always use --color=mode to say what you mean, so if you are aware of the inconsistent defaults of --color in isolation, you just avoid that construct. In other words, this is all boiling down to a bikeshed painting contest. I _do_ value consistency, and I would welcome a change that first documents our intention to make a change to a default (whether that change is to grep, to ls, to the GNU Coding Standards, or somewhere else is still up for debate), and only after another year or two go ahead with the change. But I'm not happy with forcing a change in bikeshed behavior with no warning. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#638388: bug#9326: Bug#638388: update bug addresses to point to bug-coreutils instead
tag 9326 notabug thanks [Here's hoping that the GNU debbugs bug 9326, for coreutils is closed, without negatively impacting debian bug 638388] On 08/18/2011 05:31 PM, jida...@jidanni.org wrote: Package: findutils X-debbugs-Cc: bug-coreut...@gnu.org Version: 4.5.10-1 Severity: minor According to http://article.gmane.org/gmane.discuss/14277 any mention of e.g., bug-findutils should be updated throughout this and other affected packages. I have no idea why you submitted this as a coreutils bug. The bug-findutils address that you mention is in active use by the findutils package; and a 'git grep' of 'fileutils' within the findutils package shows that findutils does not have any stale references to the old coreutils mailing aliases. Likewise for a grep of the coreutils sources - the only references to the old addresses are in historical notes. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630902: m4: FTBFS: FAIL: test-readlink
On 07/26/2011 07:50 AM, Santiago Vila wrote: Yes, most likely this is a kernel and/or glibc bug. POSIX requires readlinkat(dfd, , buf, size) to fail with ENOENT, if dfd is either AT_FDCWD or open on a directory. Which does strace say about the syscall made just before the gnulib test-readlink fails? --- SIGCHLD (Child exited) @ 0 (0) --- readlink(no_such, 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory) readlink(no_such/, 0x7fff370e7340, 80) = -1 ENOENT (No such file or directory) readlink(, 0x7fff370e7340, 80)= -1 EINVAL (Invalid argument) There's the bug. This is failing with EINVAL instead of ENOENT, which is contrary to POSIX. However, this kernel bug has already been papered over in gnulib, which means that it is merely a matter of updating m4 to use newer gnulib to make this test failure go away. http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc446909 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551093: [PATCH] doc: describe the file permissions set by mktemp
On 07/13/2011 07:25 AM, Benoît Knecht wrote: +The group and others get no permission, while the user gets read and write\n\ +permissions (as well as search, for directories), possibly reduced by the\n\ +umask.\n\ It's unfortunate that this runs onto 3 lines I completely agree. I tried to make it shorter, but couldn't come up with a good formulation. How about a one-liner: Files are created u+rw, and directories u+rwx, minus umask restrictions. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#627856: [1003.1(2008)/Issue 7 0000459]: clarification on the value of n for the shift built-in command
On 06/30/2011 05:27 PM, Austin Group Bug Tracker wrote: http://austingroupbugs.net/view.php?id=459#c880 There is no reason to wait for the next revision of the standard to make this change. The change will not break any existing implementation and clarifies that invoking shift x (where x is an integral value larger than $#) is an error that may, but need not, be considered a syntax error. In this case it is unspecified whether or not a non-interactive shell will quit when this error is detected. Or, in terms of the original question: ... could you please clarify, whether it is allowed to specify values n $# to the shift special built-in or not or whether the results are undefined. Calling things undefined would mean that there are infinite possible behaviors (core dump, reformat your drive, do nothing, ...), which there are not. Rather, this bug interpretation has clarified that the results of 'shift n # n $#' are well-defined, but that the definition has 2 permissible behaviors. Both the current bash behavior of no syntax error but non-zero status, as well as the current dash behavior of exiting on a syntax error, conform to the standard. Therefore, the fact that there are two equally valid behaviors means that an application writer must be prepared for either behavior, and the original example: while shift 1 2 /dev/null ; do domeSomethingWith $1 done is a case of a non-portable script because it was not prepared to handle the syntax error, and not a case of a bug in dash. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#630902: m4: FTBFS: FAIL: test-readlink
[adding bug-gnulib] On 06/18/2011 12:05 PM, Santiago Vila wrote: I can't reproduce the failure on Debian testing (currently using linux-image-2.6.38-2-amd64). I can reproduce it, however, on the same Debian testing system if I use the kernel currently available on unstable (linux-image-2.6.39-2-amd64). Does this mean this is a kernel bug? On 06/19/2011 10:24 AM, Santiago Vila wrote: For the record, this is what git bisect says: 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit commit 65cfc6722361570bfe255698d9cd4dccaf47570d Author: Al Viro v...@zeniv.linux.org.uk Date: Sun Mar 13 15:56:26 2011 -0400 readlinkat(), fchownat() and fstatat() with empty relative pathnames For readlinkat() we simply allow empty pathname; it will fail unless we have dfd equal to O_PATH-opened symlink, so we are outside of POSIX scope here. For fchownat() and fstatat() we allow AT_EMPTY_PATH; let the caller explicitly ask for such behaviour. Signed-off-by: Al Viro v...@zeniv.linux.org.uk Yes, most likely this is a kernel and/or glibc bug. POSIX requires readlinkat(dfd, , buf, size) to fail with ENOENT, if dfd is either AT_FDCWD or open on a directory. Which does strace say about the syscall made just before the gnulib test-readlink fails? I'll try and reproduce this setup myself, to decide whether gnulib should work around things while we wait for the kernel and/or glibc to bring things back into POSIX spec compliance, or to determine that test-readlink was over-strict and can be relaxed to allow the new behavior. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#321036: diff -L undocumented in --help and man page
On 12/30/2010 12:26 PM, Christoph Berg wrote: diff -L is neither documented in --help nor in the man page. It's documented in the info page that the man page refers to, but that's part of diff-doc and not installed with diff by default. Once -L was documented in --help (and there was no own man page, but one provided by the LDP that documented -L) in diff 2.7 (as distributed with SuSE 6.4). This is intentional. Read the NEWS file: User-visible changes in version 2.8: * The following diff options are still accepted, but are no longer documented. They may be withdrawn in future releases. -h (omit; it has no effect) -H (use --speed-large-files instead) -L (use --label instead) -P (use --unidirectional-new-file instead) --inhibit-hunk-merge (omit; it has no effect) Hi, as a further followup here: -L is used by svn diff. It would be nice if it was mentioned in the manpage and --help output as an alternative to --label, even if that's deprecated. Having to dig into the source isn't that userfriendly... 'svn diff' should be patched to use --label rather than -L. This is because a future version of diff might be taught to treat -HLP in the same manner as other recursive programs, such as chown, where -L affects how symlinks are treated during recursion. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#603895: bug#7433: ls: [manual] description for --directory is insufficient
On 11/18/2010 05:46 AM, Jari Aalto wrote: Package: coreutils Version: 8.5-1 Severity: normal [Forwarded from http://bugs.debian.org/603895 ] Thanks for the report. Manual page of ls(1) reads: -d, --directory list directory entries instead of contents, and do not derefer- ence symbolic links Which is generated from the 'ls --help' output. None of these is helpful in understanding how the option is supposed to work: ls -d The wording for -d may not mention it, but the wording at the very beginning of the --help and man page is clear that: | Usage: ls [OPTION]... [FILE]... | List information about the FILEs (the current directory by default). That is, 'ls -d' is the same as 'ls -d .', as required by POSIX, at which point you are listing the current directory as a file, and not the contents of the current directory. ls -dR When listing directories as files (-d), no recursion (-R) takes place because no directories are encountered, just files. Again, this behavior is required by POSIX. What wording change, if any, can you propose for the --help output that would not make things too verbose for what is supposed to be a quick reference? After lot of Google, a miracle command syntax is found: ls -d */ Yes, that says list all directories (and symlinks to directories) in the current directory, that don't start with leading ., as a file. Please improve the documentation and give examples. Btw, the command syntax */ is counterintuitive to rest of the ls(1) behavior: ls -avs.ls -d Yes, comparing these two in the info pages would be a useful addition (although I'm not sure that we should bloat the already-long --help output for this). Could you propose a patch? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#381091: Word splitting in 'export' arguments (Re: bash: expands $@ within double-quotes inconsistently)
On 11/05/2010 12:17 PM, Jonathan Nieder wrote:
Hi,
Current shells differ in how they split words in the arguments to
'export' and similar builtins:
A. Costa wrote:
% foo() { export x=$@ ; }
% foo -f --c
export: 4: --c: bad variable name
% echo $?
2
It seems like it should be standard code.
Remove 'export' from 'foo()' and there's no error:
% foo() { x=$@ ; } ; foo -f --c ; echo $?
0
I just tested the code in 'bash', 'ksh' and 'pdksh'; it works with no
errors. Yet in 'posh' it gives a different error:
$@ can be a pain, so for avoidance of confusion let's take another
example.
$ foo() { export x=$1; }; foo -f --c
export: 1: --c: bad variable name
The split in behaviors between shells for this construct is the same.
1. Variable expansions in what is grammatically a variable assignment
or redirection do not undergo word splitting. Variable expansions
in command names and parameters do.[1]
2. According to the grammar, variable assignments must come before the
command name.[2]
3. export is a special builtin, not a keyword, so grammatically it
behaves just like any other command.[3]
So posh and dash would seem to be correct, and the foo=bar arguments
to 'export' should be split.
On the other hand, the suppression of word splitting in export, local,
and readonly arguments by bash, ksh, and pdksh is a nice behavior that
is not likely to break current scripts. Would it make sense to tweak
the word splitting rules[1] to allow this behavior?
I would love to require altered word splitting behavior for export and
readonly (the standard doesn't touch local yet). In fact, it has
independently come up on the GNU coreutils development lists that the
standard is long overdue for requiring shells to support 'local' in
shell functions, and that standardizing local would be another reason
why word splitting rules would need to be modified.
Consider:
$ mkdir /tmp/t printf '#!/bin/sh\necho you lose\n' /tmp/t/cat
chmod a+x /tmp/t/cat
$ dash -c 'f() { b=1 PATH=/tmp/t; local z=$b; cat whatever; }; f'
you lose
$ bash -c 'f() { b=1 PATH=/tmp/t; local z=$b; cat whatever; }; f'
cat: whatever: No such file or directory
Would you like me to take a stab at writing the bug report(s) to add
support for 'local' in the next revision of the standard, and to require
the ksh/bash behavior of suppressing word splitting after shell builtins
that take arguments which can modify the current set of
shell/environment variables?
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Bug#381091: Word splitting in 'export' arguments (Re: bash: expands $@ within double-quotes inconsistently)
On 11/08/2010 03:09 PM, Jonathan Nieder wrote: Eric Blake wrote: Would you like me to take a stab at writing the bug report(s) to add support for 'local' in the next revision of the standard, and to require the ksh/bash behavior of suppressing word splitting after shell builtins that take arguments which can modify the current set of shell/environment variables? Yes, please. For suppression of word splitting, maybe something like the following would work? %token Export Readonly /* 'export' 'readonly' */ Hmm, that's rather invasive to change the grammar and make these reserved words. I'd rather go with something less invasive by modifying 2.9.1 to special-case special built-ins that take arguments which can affect the current environment, if that is possible. At any rate, the standard itself is already affected by this: line 74321 (export EXAMPLES) lists: Set and export the PATH variable: export PATH=/local/bin:$PATH without quoting of $PATH, so either we need to follow through with the intention of specifying ksh88 behavior of not needing the , or we need to fix the example. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#598768: m4: FTBFS on alpha: 1 of 93 tests failed
On 10/31/2010 04:42 PM, Santiago Vila wrote: Yes, I knew about this. I asked for help here: http://lists.debian.org/debian-alpha/2010/03/msg00015.html but had no luck. Eric Blake wrote: This is due to a known bug in the Alpha implementation of memchr: http://sourceware.org/bugzilla/show_bug.cgi?id=12019 In m4.git, branch-1.4 already has a workaround for the Alpha bug, by using a newer gnulib that detects the bug in glibc and uses a replacement memchr() and strstr(). Good to know. Simple question: Is this fixed in 1.4.15? (which I have just realized that it exist). No, but it IS fixed in m4.git branch-1.4, and I hope to release 1.4.16 this week. The latest m4.git also works around the glibc bug on all architectures (except SSE4.2) where strstr() could have false positives on certain periodic needles. http://git.sv.gnu.org/cgit/m4.git/commit/?h=branch-1.4id=5e763da32 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#593838: [PATCH] AS_LITERAL_IF: Treat raw = as literal again.
* lib/m4sugar/m4sh.m4 (_AS_LITERAL_IF): Treat = like +.
* tests/m4sh.at (AS@t...@_tr_sh and AS@t...@_tr_cpp)
(AS@t...@_literal_if): Expand tests.
* NEWS: Document the fix.
Reported via Ben Pfaff; originally http://bugs.debian.org/593838
Signed-off-by: Eric Blake ebl...@redhat.com
---
It turns out that the original Debian bug report is two for the price
of one. In autoconf-archive, AX_CFLAGS_GCC_OPTION was using an
AS_VAR_PUSHDEF'd variable incorrectly, according to the documentation.
And in Autoconf, there was indeed a regression where = was no longer
treated as a literal character to be transliterated into _ at m4 time.
This fixes the autoconf side of the equation, and adds tests to avoid
future regressions.
ChangeLog |9 +
NEWS|3 +++
lib/m4sugar/m4sh.m4 |4 ++--
tests/m4sh.at | 36 ++--
4 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 576f615..609846a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-10-08 Eric Blake ebl...@redhat.com
+
+ AS_LITERAL_IF: Treat raw = as literal again.
+ * lib/m4sugar/m4sh.m4 (_AS_LITERAL_IF): Treat = like +.
+ * tests/m4sh.at (AS@t...@_tr_sh and AS@t...@_tr_cpp)
+ (AS@t...@_literal_if): Expand tests.
+ * NEWS: Document the fix.
+ Reported via Ben Pfaff; originally http://bugs.debian.org/593838
+
2010-09-24 Joshua G. Hale jgh@gmail.com (tiny change)
docs: fix typo in AC_CONFIG_FILES example code.
diff --git a/NEWS b/NEWS
index a3a50d6..6b62542 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,9 @@ GNU Autoconf NEWS - User visible changes.
* Noteworthy changes in release ?.? (-??-??) [?]
+** AS_LITERAL_IF again treats '=' as a literal. Regression introduced in
+ 2.66.
+
* Noteworthy changes in release 2.68 (2010-09-22) [stable]
Released by Eric Blake, based on git versions 2.67.*.
diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index 13ad849..3c9350a 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -1584,8 +1584,8 @@ m4_define([AS_LITERAL_IF],
m4_define([_AS_LITERAL_IF],
[m4_if(m4_index([$1], [...@s|@]), [-1], [$0_(m4_translit([$1],
- [-:%/@{}[]#(),.$2]]]m4_dquote(m4_dquote(m4_defn([m4_cr_symbols2])))[[,
- [+$$`]))], [$0_NO])])
+ [-:=%/@{}[]#(),.$2]]]m4_dquote(m4_dquote(m4_defn([m4_cr_symbols2])))[[,
+ [++$$`]))], [$0_NO])])
m4_define([_AS_LITERAL_IF_],
[m4_if(m4_translit([$1], [+]), [], [$0YES],
diff --git a/tests/m4sh.at b/tests/m4sh.at
index 08680c3..c01027f 100644
--- a/tests/m4sh.at
+++ b/tests/m4sh.at
@@ -1278,6 +1278,10 @@ echo AS_LITERAL_HEREDOC_IF([(a)], [ok], [ERR]) 20
echo AS_LITERAL_IF([...@s|@a], [ERR], [ok]) 21
echo AS_LITERAL_WORD_IF([...@s|@a], [ERR], [ok]) 22
echo AS_LITERAL_HEREDOC_IF([...@s|@a], [ERR], [ok]) 23
+echo AS_LITERAL_IF([${a+b}], [ERR1], [ok], [ERR2]) 24
+echo AS_LITERAL_IF([${a=b}], [ERR1], [ok], [ERR2]) 25
+echo AS_LITERAL_IF([a+b], [ok], [ERR1], [ERR2]) 26
+echo AS_LITERAL_IF([a=b], [ok], [ERR1], [ERR2]) 27
]])
AT_CHECK_M4SH
@@ -1305,6 +1309,10 @@ ok 20
ok 21
ok 22
ok 23
+ok 24
+ok 25
+ok 26
+ok 27
]])
AT_CLEANUP
@@ -1342,12 +1350,13 @@ echo AS_TR_CPP(`echo abc`) AS_TR_CPP(`echo aBc`)
AS_TR_CPP(`echo ABC`)
echo AS_TR_CPP([`echo abc`]) AS_TR_CPP([`echo aBc`]) AS_TR_CPP([`echo ABC`])
echo AS_TR_CPP([[`echo abc`]]) AS_TR_CPP([[`echo aBc`]]) AS_TR_CPP([[`echo
ABC`]])
echo ===
-echo AS_TR_SH([a.b/c+*-])
-echo AS_TR_CPP([a.b/c+*-])
-var=a.b/c+*-
+# start here
+echo AS_TR_SH([a.b/c+*-=])
+echo AS_TR_CPP([a.b/c+*-=])
+var=a.b/c+*-=
echo AS_TR_SH([$var])
echo AS_TR_CPP([$var])
-m4_define([macro], [a.b/c+*-])
+m4_define([macro], [a.b/c+*-=])
echo AS_TR_SH([macro])
echo AS_TR_CPP([macro])
]])
@@ -1375,12 +1384,19 @@ HI ABC HI
HI ABC HI
ABC ABC ABC
===
-a_b_cpp_
-A_B_C_P_
-a_b_cpp_
-A_B_C_P_
-a_b_cpp_
-A_B_C_P_
+a_b_cpp__
+A_B_C_P__
+a_b_cpp__
+A_B_C_P__
+a_b_cpp__
+A_B_C_P__
+]])
+
+dnl Check that of the last 6 macros, only 2 needed command substitution.
+dnl This test abuses our knowledge of m4sh internals a bit; oh well.
+AT_CHECK([sed -n '/start here/,$ {
+/`.*`/p
+}' script | wc -l], [], [[2
]])
AT_CLEANUP
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598768: m4: FTBFS on alpha: 1 of 93 tests failed
On 10/01/2010 05:08 AM, Cyril Brulebois wrote: Source: m4 Version: 1.4.14-3 Severity: important User: debian-al...@lists.debian.org Usertags: ftbfs Hi, your package no longer builds on alpha: | PASS: test-strsignal | /bin/bash: line 1: 20065 Segmentation fault EXEEXT='' srcdir='.' LOCALE_FR='none' LOCALE_FR_UTF8='none' LIBSIGSEGV='' LOCALE_FR='none' LOCALE_TR_UTF8='none' LOCALE_FR='none' LOCALE_FR_UTF8='none' LOCALE_JA='none' LOCALE_ZH_CN='none' LOCALE_FR_UTF8='none' LOCALE_FR='none' LOCALE_FR_UTF8='none' LOCALE_FR='none' LOCALE_FR_UTF8='none' PATH='/build/buildd-m4_1.4.14-3-alpha-15kV7D/m4-1.4.14/build-aux':$PATH PATH='/build/buildd-m4_1.4.14-3-alpha-15kV7D/m4-1.4.14/build-aux':$PATH LOCALE_FR='none' LOCALE_FR_UTF8='none' LOCALE_JA='none' LOCALE_ZH_CN='none' $tst test-strstr.log-t 21 | FAIL: test-strstr | […] | 1 of 93 tests failed | (10 tests were not run) Full build logs: https://buildd.debian.org/status/package.php?p=m4 This is due to a known bug in the Alpha implementation of memchr: http://sourceware.org/bugzilla/show_bug.cgi?id=12019 In m4.git, branch-1.4 already has a workaround for the Alpha bug, by using a newer gnulib that detects the bug in glibc and uses a replacement memchr() and strstr(). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593838: Bug #593838: AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable
On 09/25/2010 12:22 PM, Ben Pfaff wrote: retitle 593838 AX_CFLAGS_GCC_OPTION misuses AS_VAR_PUSHDEF variable reassign 593838 autoconf-archive thanks Jerome BENOITjgm...@rezozer.net initially reported that AX_CFLAGS_GCC_OPTION(-std=c99) fails with Autoconf 2.67. Vincent Bernatber...@debian.org determined that the bug could be fixed by replacing a literal shell assignment by AS_VAR_SET. Just now, I took a closer look. I was able to reduce the problem to the following trivial case: --8--cut here--8-- AC_DEFUN([MY_MACRO], [AS_VAR_PUSHDEF([VAR],[prefix_$1]) dnl This is the version used by AX_CFLAGS_GCC_OPTION. dnl I believe that it is incorrect. It does not work on Autoconf= 2.67. VAR=the_value You are correct that this will not work if VAR is an indirect variable name. It all depends on whether $1 is determined to be an indirection. MY_MACRO([blah]) is direct; it expands to AS_VAR_PUSHDEF([VAR],[prefix_blah]), at which point VAR is the literal string prefix_blah, and you still have valid shell code (by sheer luck, and not because you followed the documentation). But foo=bar MY_MACRO([$foo]) is indirect; it expands to AS_VAR_PUSHDEF([VAR],[prefix_$foo]), and you MUST use AS_VAR_SET([VAR]) in order to set the shell variable prefix_bar (as that is what the indirection results in). Direct use of VAR as a shell-variable name will result in invalid shell code. On that basis, I infer that one is not supposed to use the M4-NAME literally, and thus I believe that this is a bug in AX_CFLAGS_GCC_OPTION. So, I am reassigning this bug to autoconf-archive (with this email). That is the correct course of action. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593838: autoconf: macro AX_CFLAGS_GCC_OPTION does not work with equation argument (as '-std=c99')
[adding autoconf-archive list, as owner of the AX_CFLAGS_GCC_OPTION macro] On 08/21/2010 07:52 AM, Ralf Wildenhues wrote: tags + upstream thanks [ http://bugs.debian.org/593838 ] Hi Jerome, * Jerome BENOIT wrote on Sat, Aug 21, 2010 at 02:58:28PM CEST: Version: 2.67-2 AX_CFLAGS_GCC_OPTION(-std=c99) produces a boggus configure script. Confirmed with upstream git Autoconf: catconfigure.ac\END AC_INIT AX_CFLAGS_GCC_OPTION(-std=c99) END aclocal -I /path/to/autoconf-archive/m4 autoconf ./configure [...] checking CFLAGS for gcc -std=c99... ./configure: line 2493: ax_cv_cflags_gcc_option__std_c99=no, unknown: command not found ./configure: line 2516: ax_cv_cflags_gcc_option__std_c99=-std=c99: command not found I'm wondering if the AX_CFLAGS_GCC_OPTION macro is at fault here, or if it is a true regression in autoconf. Because it appeared that the trouble comes from the equal (`=`) I guess it is an autoconf issue: line as AX_CFLAGS_GCC_OPTION(-Wno-unused-function) works well. Note that with the previous version of autoconf (2.65-4) everything was fine. As a matter of fact, I suspect that the issue may be related to bug #593546 , but I can not confirm this part of the story. Related yes, but #593546 is about '*' and this is about '='. I think it is obvious that something changed so that AX_CFLAGS_GCC_OPTION is no longer transliterating = into _ when creating the cache variable name. But I don't know where the fault lies without seeing the implementation of this macro. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580492: bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash
On 05/06/2010 05:15 AM, Vincent Lefevre wrote: Hi, I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580492 That bug should be reassigned to busybox. With the basename and dirname utilities from GNU Coreutils, one has: ypig% POSIXLY_CORRECT=1 basename -- basename: missing operand Correct. ypig% busybox basename -- -- Buggy. According to POSIX[*], basename and dirname take no options (examples in POSIX also assume that), so that this would make BusyBox's behavior correct. No, you're missing one other key point of POSIX: http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Section 1.4, OPTIONS: Default Behavior: When this section is listed as None., it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize -- as a first argument to be discarded. The requirement for recognizing -- is because conforming applications need a way to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo is listed as taking no options, and the application needed to give it a pathname with a leading hyphen, it could safely do it as: foo -- -myfile and avoid any problems with -m used as an extension. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#580492: bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash
On 05/06/2010 07:41 AM, Eric Blake wrote: According to POSIX[*], basename and dirname take no options (examples in POSIX also assume that), so that this would make BusyBox's behavior correct. No, you're missing one other key point of POSIX: http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Section 1.4, OPTIONS: If you want more evidence from POSIX that 'basename -- foo' is mandated behavior, read up on this correction to POSIX: http://austingroupbugs.net/view.php?id=192 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#580492: bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash
On 05/06/2010 07:23 AM, Vincent Lefevre wrote: If one follows POSIX, the correct way to do it is: base=$(basename $path) and this is robust because the first argument is necessarily the path (it cannot be an option, even --). POSIX does not forbid applications from adding extension options. And BSD basename has done just that: SYNOPSIS basename string [suffix] basename [-a] [-s suffix] string [...] dirname string [...] And since POSIX allows FreeBSD's extensions to exist (although a portable script will not use them), it must also require that a portable app be able to guarantee a way to bypass those extensions (ergo base=$(basename -- $path) is a POSIX requirement). According to grep 'basename --' /usr/bin/* grep 'basename \$' /usr/bin/* on my Debian machine, almost all scripts use basename without --. The only exceptions are autoconf (but I'm not sure this counts, as there's a test for basename -- first, Can you find an actual example of this? I think you read it incorrectly, as really, autoconf first tests for 'basename -- /', but if you indeed found an instance of autoconf testing for 'basename --', that would be a bug in autoconf that needs to be reported to that list. Note solaris behaves like busybox and openbsd behaves like coreutils. Perhaps they're copying coreutils without looking at what POSIX says. Or, more likely, perhaps they are independently obeying what POSIX says, without reference to either coreutils or busybox. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#580492: bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash
On 05/06/2010 08:24 AM, Vincent Lefevre wrote: Default Behavior: When this section is listed as None., it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize -- as a first argument to be discarded. OK, an alternative way would be that an exception is added to POSIX, just like for echo. Please no. echo has an exception precisely because it has historical baggage, and that is what makes echo so pitiful that POSIX itself states that printf(1) is more portable than echo(1). Relatively newer applications, like basename and dirname, that were first written in an age when consistency was more important, should not be burdened with the historical baggage of ancient echo(1). And changing it now is too late; just as you argue about the number of broken scripts that are not robust because they failed to use --, you have to also consider the number of correct scripts that have been written with the correct assumption that basename and dirname accept --: it has been 9 years since POSIX 2001 first codified that behavior. Besides, we would much prefer to keep 'basename --help' as a GNU extension. Not having 'POSIXLY_CORRECT=1 /bin/echo --help' give useful help is an annoyance that we would rather avoid repeating. However, if extensions are allowed, this would mean that many scripts would have to be fixed. Yes, many broken scripts need to be fixed. But that is the fault of those broken scripts, not coreutils. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#580492: bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash
On 05/06/2010 09:38 AM, Vincent Lefevre wrote: there's a test for basename -- first, Can you find an actual example of this? I think you read it incorrectly, as really, autoconf first tests for 'basename -- /', but if you indeed found an instance of autoconf testing for 'basename --', that would be a bug in autoconf that needs to be reported to that list. Sorry, I meant it was testing basename with -- as the first argument while in this case it is useless. So, I wondered whether the goal of this test was to test whether this form was supported. Yes, the goal of that autoconf test is to determine whether basename(1) supports leading --, as required by POSIX. Or, more likely, perhaps they are independently obeying what POSIX says, without reference to either coreutils or busybox. So, I think I should reassign the bug to busybox? Yes. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#503840: ash: . not recognising -- as the end-of-options
The Austin Group (the folks who write POSIX) are considering changing POSIX to require that . support --: http://austingroupbugs.net/view.php?id=252 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Bug#563726: [Bug 552320] Handling AT_FDCWD as EBADF in glibc's utimens() causes tar failures
According to Jim Meyering on 1/5/2010 2:07 PM:
https://bugzilla.redhat.com/show_bug.cgi?id=552320
Thanks for the heads up. Good timing.
That does indeed look like a bug, and Aurelien Jarno's fix seems right.
I can confirm that the fix is correct.
I expect to push the following to gnulib in the morning:
From e7d83f123f5eed312523252c066510b5de0f7cd1 Mon Sep 17 00:00:00 2001
From: Aurelien Jarno aurel...@aurel32.net
Date: Tue, 5 Jan 2010 21:31:41 +0100
Subject: [PATCH] utimens (fdutimens): ignore a negative FD, per contract
* lib/utimens.c (fdutimens) [HAVE_FUTIMENS]: Call futimens only
when we have a valid file descriptor. Otherwise, using a brand
new glibc (with just-patched futimes that now fails with EBADF)
s/futimes/futimens/ (ChangeLog and commit message)
+++ b/lib/utimens.c
@@ -264,19 +264,20 @@ fdutimens (char const *file, int fd, struct timespec
const timespec[2])
}
# endif /* HAVE_UTIMENSAT */
# if HAVE_FUTIMENS
- {
-result = futimens (fd, ts);
+ if (0 = fd)
+ {
Why the TAB? We just got rid of those in gnulib.
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
signature.asc
Description: OpenPGP digital signature
Bug#563118: du cannot sort its output without help from other programs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Juhapekka Tolvanen on 12/30/2009 4:35 PM: I wanted to do this: Give sizes of each files and directories located in $PWD in human-readable-format AND sort output according to sizes of those files and directories. What's wrong with: du -sh0 * | sort -hz | tr '\0' '\n' besides needing coreutils 7.5 or newer? But it would be much easier, if du had some sorting functionalities. Rather, it IS much easier by using du's nul-termination functionality, coupled with sort's nul-termination and human-size sorting. Use each tool for what it is good at. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks8nbcACgkQ84KuGfSFAYDlgACgw0pEnqORZyCR51Lnk13bCrGm VxEAn2eK5wZ/etcchnghx6OqCgH98UWt =w2Bj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560105: autoconf: AC_TYPE_INT32_T generates broken test?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 12/8/2009 11:25 PM: * Ralf Wildenhues wrote on Tue, Dec 08, 2009 at 11:59:26PM CET: * Pierre Ynard wrote on Tue, Dec 08, 2009 at 11:42:02PM CET: AC_TYPE_INT32_T, and also AC_TYPE_INT16_T and AC_TYPE_INT64_T, output C code that looks like: Patch below. OK to commit and add Pierre to THANKS? Yes, please. I think we need to start comparing test results against tables for at least a couple of systems, in order to guard against such issues. My current idea for this is to have a mode in which AT_CHECK_MACRO records cache values, or we simply run `testsuite -d' and collect cache values across all tests, maybe weeding out or commenting out those that are not consistent across the testsuite; then redo the same for an older release, and compare. Not as part of this patch, but the idea seems like it might be worthwhile. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksfmigACgkQ84KuGfSFAYBGYQCZARbU/kagiplAzOdCO7t7vrCX /LkAnjIfRjNGaeHfcSa7VkH76766hs4k =kyCF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557632: broken test for mmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 11/24/2009 3:37 AM: what leads to not detecting mmap on Debian and because of this some packages fail to build (I did hit this on sdcv). Proposed patch. Fixes the test with CC=g++. OK to apply and add Michal to THANKS? Yes, this looks reasonable. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksL13AACgkQ84KuGfSFAYBSewCgrlhWT7qqI1MMc7jI9QKu2ciP XkUAnAkmuXKpCkvTm/EG4QyeNufCzcEQ =no+1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539481: coreutils: [df] Please use DOT instead of COMMA in -h (human readable) size listing
$ df -hl | grep usb /dev/sdb1 3,9G 3,9G 96K 100% /media/usb0 /dev/sdc1 3,8G 4,0K 3,8G 1% /media/usb1 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Not a bug. Your locale uses comma as the decimal separator; if you want '.', then use a different locale. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021 Try: $ LC_ALL=C df -hl | grep usb to see the difference. -- Eric Blake -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489046: findutils: find -execdir + doesn't work anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Adam Borowski on 3/31/2009 1:40 AM: http://savannah.gnu.org/bugs/?19593 Instead of tweaking the docs -- or perhaps in addition to -- let's think how to fix the behaviour. What about doing a dup() on the directory, and comparing the paths once the next match is found? That would have a side effect of delaying execution if there's no match for a long time, but I think that's still much better than doing just one file. Doing a dup() is counterproductive. It puts increased pressure on the number of open file descriptors, particularly if your hierarchy is deep, but we don't want to trigger EMFILE failures. Additionally, it triggers bugs in some network filesystems, which report a cached 32-bit inode value; this value is consistent when used with locality of reference, but when stored over a long period of time with a large number of file traversals in between, the cache recycles, and the same file/directory can appear with a different inode. You can search the gnulib mail archives for more details about how fts had to be recoded to avoid triggering this bug, and the impact that it had on coreutils. The real fix has to be an interface change to gnulib's fts to make it obvious when a directory is changing, in order to make it easier for find to group multiple files found from a single directory. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknSNQkACgkQ84KuGfSFAYAqJgCeL06AbvO5kXnArEFbfmQWbEJD MpQAnjfRmC1GNENAHBWFcN3zijJfuxiT =nW6d -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#312873: Specifying Names manual node has a different header
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Russ Allbery on 3/12/2009 10:19 PM:
Hello, and sorry for my delay,
A Debian user noticed that the Specifying Names node in the Autoconf
manual has a heading of Specifying the System Type. The nodes don't
necessarily have the same name as the page titles, I realize, but in this
case I think the node name is a bit confusing. Specifying Names sounds
like a rather more generic topic than system types. I think it may be
worthwhile to rename this node to Specifying the System Type (or,
shorter, Specifying System Types) to match its heading.
Thanks for the report. Even worse, there are two nodes with an entry of
@section Specifying the System Type, one in the chapter Manual
Configuration (@node Specifying Names), and one in the chapter Running
`configure' scripts (@node System Type). I'll be pushing this soon.
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm/mfQACgkQ84KuGfSFAYAt3QCdHv7hte0bfKlHwDgQ3mio8e15
wfgAoNLJdU2N+OERuspEq7ueo/BaBrIR
=Q4+p
-END PGP SIGNATURE-
From e5f657f31e671e95c4989a2840d5053ed1f3cda6 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Tue, 17 Mar 2009 06:38:07 -0600
Subject: [PATCH] Improve confusing section names.
* doc/autoconf.texi (Specifying Names): Rename node...
(Specifying Target Triplets): ...to this.
(Generic Programs): Adjust references.
* doc/install.texi (System Type): Touch up formatting.
* THANKS: Update.
Reported by Tim Freeman, in http://bugs.debian.org/312873.
Signed-off-by: Eric Blake e...@byu.net
---
ChangeLog |8
THANKS|1 +
doc/autoconf.texi | 28 +++-
doc/install.texi |5 +++--
4 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 8f9cd54..9a5fd5d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2009-03-17 Eric Blake e...@byu.net
+ Improve confusing section names.
+ * doc/autoconf.texi (Specifying Names): Rename node...
+ (Specifying Target Triplets): ...to this.
+ (Generic Programs): Adjust references.
+ * doc/install.texi (System Type): Touch up formatting.
+ * THANKS: Update.
+ Reported by Tim Freeman, in http://bugs.debian.org/312873.
+
Remove historical inaccuracy.
* doc/autoconf.texi (Portable Shell): Don't perpetuate myth about
#!/bin/sh needing a space.
diff --git a/THANKS b/THANKS
index 5cb10cb..c3e19a2 100644
--- a/THANKS
+++ b/THANKS
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 874d139..e821cbd 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -537,7 +537,7 @@ Top
Manual Configuration
-* Specifying Names::Specifying the system type
+* Specifying Target Triplets:: Specifying target triplets
* Canonicalizing:: Getting the canonical system type
* Using System Type:: What to do with the system type
@@ -4058,7 +4058,7 @@ Generic Programs
If the tool cannot be found with a prefix, and if the build and target
types are equal, then it is also searched for without a prefix.
-As noted in @ref{Specifying Names, , Specifying the system type}, the
+As noted in @ref{Specifying Target Triplets}, the
target is rarely specified, because most of the time it is the same
as the host: it is the type of system for which any compiler tool in
the package produces code. What this macro looks for is,
@@ -4084,8 +4084,7 @@ Generic Programs
When cross-compiling, this macro will issue a warning if no program
prefixed with the host type could be found.
-For more information, see @ref{Specifying Names, , Specifying the
-system type}.
+For more information, see @ref{Specifying Target Triplets}.
@end defmac
@defmac AC_CHECK_TARGET_TOOLS (@var{variable}, @var{progs-to-check-for}, @
@@ -4118,8 +4117,7 @@ Generic Programs
When cross-compiling, this macro will issue a warning if no program
prefixed with the host type could be found.
-For more information, see @ref{Specifying Names, , Specifying the
-system type}.
+For more information, see @ref{Specifying Target Triplets}.
@end defmac
@anchor{AC_PATH_PROG}
@@ -4197,8 +4195,7 @@ Generic Programs
When cross-compiling, this macro will issue a warning if no program
prefixed with the host type could be found.
-For more information, see @ref{Specifying Names, , Specifying the
-system type}.
+For more information, see @ref{Specifying Target Triplets}.
@end defmac
@@ -18972,18 +18969,22 @@ Manual Configuration
Autoconf provides a uniform method for handling unguessable features.
@menu
-* Specifying Names::Specifying the system type
+* Specifying Target Triplets:: Specifying target triplets
* Canonicalizing
Bug#466990: Portability problems of Usual Tools not described in manual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 3/17/2009 8:43 AM:
Thanks for the report. I would like to verify these claims before
applying any patches, but agree that they are probably worth mentioning.
1. sed behaves entirely unpredictable on lines that are not
newline-terminated.
Confirmed. POSIX states that sed is only required to operate on text
files, and also that a file without a trailing newline is not a text file.
This has actually already been done:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=b2bde72
2. On HP-UX 11.23, regexp matching with expr does not allow multiple sub-
expressions:
bash-3.1$ expr 'Xfoo' : 'X\(f\(oo\)*\)$'
expr: More than one '\(' was used.
Ouch. I don't have access to HP-UX to verify, but this means we need to
audit autoconf source to make sure we don't violate this restriction.
3. On GNU/Linux the regexp $, when used with older versions of expr,
matches newlines embedded in the match string:
bash-3.1$ baz='foo
bar'
bash-3.1$ expr X$baz : 'X\(foo\)$' || echo baz
foo
I'm assuming this was from an older version of coreutils? Can someone
determine 'expr --version' in the broken case, to see when it was fixed?
Both expr issues are mentioned in this patch, now applied:
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknAT7QACgkQ84KuGfSFAYCb8ACfdcGsMmGLQ/QKlXoBbclnhVAr
X6oAoMP2yNoZyxlxLP7eqWzbZqWch0K1
=16+4
-END PGP SIGNATURE-
From abee382683d1b977f2ab4a91121b4277045e6d5a Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Tue, 17 Mar 2009 19:33:08 -0600
Subject: [PATCH] Manual: mention more expr pitfalls.
* doc/autoconf.texi (Limitations of Usual Tools) expr (:):
Mention HP-UX limitation, and $ ambiguity.
* THANKS: Update.
Reported by Jens Schmidt, in http://bugs.debian.org/466990.
Signed-off-by: Eric Blake e...@byu.net
---
ChangeLog |8
THANKS|1 +
doc/autoconf.texi | 23 +++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 259004e..3829924 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2009-03-18 Eric Blake e...@byu.net
+
+ Manual: mention more expr pitfalls.
+ * doc/autoconf.texi (Limitations of Usual Tools) expr (:):
+ Mention HP-UX limitation, and $ ambiguity.
+ * THANKS: Update.
+ Reported by Jens Schmidt, in http://bugs.debian.org/466990.
+
2009-03-17 Jim Meyering meyer...@redhat.com
Manual: fix a typo.
diff --git a/THANKS b/THANKS
index c3e19a2..8d8bb37 100644
--- a/THANKS
+++ b/THANKS
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index a0a19b8..a4cb0d1 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16642,6 +16642,21 @@ Limitations of Usual Tools
@samp{^}. Patterns are automatically anchored so leading @samp{^} is
not needed anyway.
+On the other hand, the behavior of the @samp{$} anchor is not portable
+on multi-line strings. Posix is ambiguous whether the anchor applies to
+each line, as was done in older versions of @acronym{GNU} Coreutils, or
+whether it applies only to the end of the overall string, as in
+Coreutils 6.0 and most other implementations.
+
+...@example
+$ @kbd{baz='foo}
+ @kbd{bar'}
+$ @kbd{expr X$baz : 'X\(foo\)$'}
+
+$ @kbd{expr-5.97 X$baz : 'X\(foo\)$'}
+foo
+...@end example
+
The Posix standard is ambiguous as to whether
@samp{expr 'a' : '\(b\)'} outputs @samp{0} or the empty string.
In practice, it outputs the empty string on most platforms, but portable
@@ -16718,6 +16733,14 @@ Limitations of Usual Tools
1
@end example
+On @acronym{HP-UX} 11, @command{expr} only supports a single
+sub-expression.
+
+...@example
+$ @kbd{expr 'Xfoo' : 'X\(f\(oo\)*\)$'}
+expr: More than one '\(' was used.
+...@end example
+
@item @command{fgrep}
@c --
--
1.6.1.2
Bug#472590: RFC: changing the + in ls -l output to be . or +
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Mike Edenfield on 10/24/2008 7:19 AM: Based on the kind of real-world problems I've had, the most useful thing ls could tell me about a file on my SELinux system would be that it *should* have a label and *doesn't*, something like: if ( selinux_enabled ) if ( label == NULL || label == fs.defaultlabel ) use ! else use Unfortunately, that would violate POSIX, which requires ' ' in the case when no alternate access controls are in force. And SELinux contexts count as an alternate access control. The optional alternate access method flag shall be a single space if there is no alternate or additional access control method associated with the file; otherwise, a printable character shall be used. http://www.opengroup.org/onlinepubs/009695399/utilities/ls.html - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkBzw8ACgkQ84KuGfSFAYCXAACeN4uUaHlCuBXUMFeJLsBDyShJ AGIAniTtjas6Urnz/P92Vhr/JFx19oZC =ibH3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 9/11/2008 11:56 AM: As I read the spec, chown and chgrp are explicitly required to make the equivalent of a chown() call, which in turn is required to change the ctime. However, chmod is not required to make the equivalent of a chmod() call, and there is no requirement in the 'chmod' spec that it change the ctime. So POSIX allows the optimization for the 'chmod' command, but not for the 'chown' and 'chgrp' commands. On the other hand, the POSIX spec for chmod(1) mentions that it is implementation defined on how it affects alternate access control. I have come to expect on many systems that support ACLs, that 'chmod 755' on a file with rwxr-xr-x+ permissions will remove the ACLs. In other words, optimizing away the chmod(2) call because it compares equal to the stat information would break this side-effect of clearing ACLs. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjJ3/UACgkQ84KuGfSFAYAjhACdFl0013RJgN8wk9ay0tO0Icts tiEAoKH2Sp5qaStFBGRo61omIOPCUMGO =zlNv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276500: #276500: utimensat added as syscall
For what it's worth, coreutils 6.12 and newer now use utimensat if available; and when coupled with a new enough kernel, no longer demonstrate the original issue reported against touch(1). However, in testing the coreutils patch to use utimensat, it was discovered that at least some versions of the kernel have a buggy utimensat syscall that return a bogus positive number instead of -1 on failure: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=9840199 -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478065: misleading output from AC_PROG_AWK
According to Ralf Wildenhues on 6/19/2008 11:42 AM: checking for gawk... (cached) awk In this case, awk is not gawk, and configure is not actually searching for gawk, so this AC_PROG_AWK output is misleading. What are the alternatives? - output a line for each name we check, or even each directory? Both is waaay too verbose; AC_PROG_FC, for example, checks for something like two dozen names. - checking for AWK or (shudder) checking for @AWK@? Hmm. - adding new macro arguments to override what's printed? IMVHO not worth the hassle in this case. I don't think changing the code for this issue is worth the drawbacks. Of those three, I would only consider a patch that does the second variant (or maybe checking for $AWK) - the first and third are not worth it. But it doesn't bother me enough to write such a patch. Second, in your case, './configure AWK=awk', checking is not done at all. I see the point that there is a difference between configure searched for this program before, but did not find it, so used this alternative instead and the user overrides the search algorithm with this value. We could change it to output something like | checking for gawk... (user-provided) awk One drawback is that this may be wrong, too, for example when AWK is passed from one configure script to the next (maybe (set in $AWK) instead?). Now that seems like a relatively simple idea. So the possible output cases would be: user did nothing, and awk is the final program found after a full search: | checking for gawk... awk user did nothing, and the cache was used: | checking for gawk... (cached) awk user supplied AWK: | checking for gawk... (set in $AWK) awk Here's where to stick a one-liner patch that would do this (although I haven't tested it, so it may need some quoting adjustments, and certainly needs a testsuite addition); does this approach sound good enough to pursue further? 2008-06-20 Eric Blake [EMAIL PROTECTED] * lib/autoconf/programs.m4 (_AC_CHECK_PROG): Inform user when path search was skipped because of an environment variable. Reported by Clint Adams via Ben Pfaff. diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4 index e7e72c0..ad248b7 100644 --- a/lib/autoconf/programs.m4 +++ b/lib/autoconf/programs.m4 @@ -66,6 +66,7 @@ set dummy $2; ac_word=$[2] AC_MSG_CHECKING([for $ac_word]) AC_CACHE_VAL(ac_cv_prog_$1, [if test -n $$1; then + _AS_ECHO_N([(set in $$1) ]) ac_cv_prog_$1=$$1 # Let the user override the test. else m4_ifvaln([$6], -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388684: coreutils: info ls opens the man page, not the info documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/26/2008 11:39 AM: | | I've just applied this: | | 2008-01-26 Jim Meyering [EMAIL PROTECTED] | | Emit info coreutils 'PROG invocation' into the man page, | rather than just info PROG. The latter would often fail | or simply display the man page. | * man/help2man: Change the template. | Prompted by http://bugs.debian.org/399684 However, the info manual recommends: | So, there is a convention to name such sections with a phrase | beginning with the word `Invoking', as in `Invoking Emacs'; this way, | users can find the section easily. Maybe the better fix would be renaming all the nodes in coreutils.texi to comply with this convention? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHm4RH84KuGfSFAYARAopMAKCa9XH+SpTrVS5BhPyywFvHApQn9ACeJ7TI kfl79LSgDAdZlrt5kU3OrX8= =a5cT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451346: m4:debian/sendmail.mc:18: ERROR: end of file in string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 11/19/2007 2:52 AM: Eric Blake a écrit : I'm the m4 maintainer, and am not using debian myself, so I don't have direct access to the files you are mentioning A bit surprising on bugs.debian.org ;) That's because anyone is allowed to subscribe to debian bug feeds, whether or not they use debian. I have found that debian bug reports for m4 tend to flush out issues that also affect other platforms, so I subscribed in order to improve m4. However, in this case, there is no m4 bug. Here's the whole directory /usr/share/sendmail hoping it will help ;) Yep. cf.m4 includes cfhead.m4, which does changecom(^A), which means that # no longer starts m4 comments. That means that text that follows # is live to m4, and thus the line: # * `sendmailconfig` in sendmail.mc is starting an unterminated doubly-nested quoted string, rather than being a comment. This is a sendmail bug, not an m4 bug. cfhead.m4 should probably be changed to call changecom(`#') after it has done all its work, once again making # start comments in the user file, so that text in the user comments is no longer live to m4. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQY4K84KuGfSFAYARAh8oAJ9XlOe5DM2df1jZUw8pjhEakaFJ5ACffitR YDgO6B6sDFrjf16ga2IW2BU= =4Bz1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451346: m4:debian/sendmail.mc:18: ERROR: end of file in string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 11/15/2007 1:16 AM: m4:debian/sendmail.mc:18: ERROR: end of file in string when running m4 on the default sendmail.mc file. After anylizing the mentioned line # * `sendmailconfig` and making a few tests it appears that if I remove the antiquotes ` there is no more error I need to see more context before I can determine whether this is, as I suspect, a quoting bug in your sendmail.mc file and not a bug in m4. For example, was line 18 inside a macro definition, and what were the current quote and comment delimiters? Please attach the sendmail.mc file that was causing the problems. This chapter in the m4 manual may be helpful: http://www.gnu.org/software/m4/manual/html_node/Pseudo-Arguments.html#Pseudo-Arguments It gives an example where an unquoted comment occurs _inside a macro call_, and as a result, changes the behavior of the rescanning algorithm to be less than intuitive. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPEWH84KuGfSFAYARAsWHAJ0U39U7C43BjpzgmZFgzDQNQBq2DQCgrru2 UmuUK8Y9e/tSpC0iWftA8+4= =oUYJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451346: m4:debian/sendmail.mc:18: ERROR: end of file in string
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 11/15/2007 7:46 AM: Hello, the problem is that the sendmail.mc file, I'm talking about is the default one in my out of the box debian server... I'm the m4 maintainer, and am not using debian myself, so I don't have direct access to the files you are mentioning unless you send them to me. Maybe the debian packager will speak up on this matter soon. m4 /usr/share/sendmail/cf/m4/cf.m4 /etc/mail/sendmail.mc You've now attached the problem lines in /etc/mail/sendmail.mc, but without knowing the context of /usr/share/sendmail/cf/m4/cf.m4, I don't know what the current quote and comment delimiters are at the time sendmail.mc is parsed. I can't reproduce the problem on my machine, given the information presented so far, but lacking the exact files you are parsing. My suspicion is still that this is not an m4 bug, but a bug in cf.m4 that is causing the lines in sendmail.mc to be interpreted with different quoting rules than what you are normally used to. Also, some lines wrapped in your sendmail.mc example; consider attaching the file so that line wraps don't ruin it. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPn0R84KuGfSFAYARAgnNAJkBpGeJdA3sQg++gSXDrOTH90Ur/ACgoCSK wZjVUVROlBrUKELQ6r53Vc8= =O7ze -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389432: mv: cannot move directory into an already populated directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/25/2006 3:51 PM: $ mkdir -p 1/a/b 2/a/c $ mv 1/a 2/ mv: cannot move `1/a' to a subdirectory of itself, `2/a' $ rmdir 2/a/c $ mv 1/a 2/ $ Thanks for the report, but mv can't do that -- at least not by default. It might make sense to add an option to make mv work this way, if you can make a good enough case for it. This capability is present in Windows. When you move one subtree into another folder that contains a similar subtree, the gui prompts whether the move should proceed to update all contents by the same name. Being able to do this from a command line would be rather nice. I would suggest the name --merge for both cp and mv. Semantics would be that directories encountered during the traversal of the subtrees are handled specially, such that destination directory ends up as the merge of the two subtrees (any relative name present in both source and destination trees comes from the source, all other relative file names in the destination remain unchanged). But of course, without an actual patch, this is just wishful thinking for now... - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGJWo84KuGfSFAYARAko/AJsGzpmrlXga16i74vp/IDYCItBJKgCeNgS0 8cDTD4HUt+FNOLNrvbNNCbU= =jR/2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389170: coreutils: mv -v fails on hardlinked files
And the result would be correct wether x is removed, or y was replaced (I see this similar to rm not doing the same thing as unlink to achieve removal of a name, but resorting to a variety of syscalls). This corner case is problematic in POSIX. The fact that GNU even removes x is counter to a strict reading of POSIX, which requires that mv defer to rename(2), and that rename is a no-op when the old and new name refer to the same file (even when it is two different names of a hard link). But this is so counter-intuitive that GNU has chosen to break with POSIX on this regards (except perhaps under POSIXLY_CORRECT; I'd have to re-read the source to be sure). So I'm not sure if Jim should spend much more effort improving the verbose output; the fact that it is different already goes to show that hard links are a special case. -- Eric Blake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#5898: debian bug 5898 - security option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 7/31/2006 9:04 PM:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5898
Yes, you read that right - an open bug with only a 4-digit ID. 9 years
and 236 days old.
The idea might be nice for m4 2.0, but is not worth adding to the 1.4.x
branch. My take on what a --secure option would disable:
debugfile (it can overwrite arbitrary existing files)
syscmd (it invokes arbitrary shell commands)
esyscmd (likewise)
maketemp (invoked enough times, it can form a denial-of-service by
creating lots of files)
builtin (at least, builtin on any of the restricted commands)
And here is my first cut at this patch, which will be in the eventual m4
2.0. The door is open for using -S with no arguments as a short option
for --safer, but I did not make that change now, since it is incompatible
with the existing (but intentionally undocumented) -Sint option for
compatibility with Solaris m4.
2006-09-14 Eric Blake [EMAIL PROTECTED]
Add --safer option, per debian bug 5898.
* src/main.c (usage): Document new option.
(SAFER_OPTION): New enumerator.
(main): Set the option bit.
* m4/m4module.h (m4_context_opt_bit_table): Declare new bit
accessors.
* m4/m4private.h (M4_OPT_SAFER_BIT): New macro.
(m4_get_safer_opt): New accessor.
* modules/gnu.c (esyscmd, debugfile): Disable when --safer.
* modules/m4.c (syscmd, maketemp): Likewise.
* doc/m4.texinfo (Invoking m4, Debug Output, Syscmd, Esyscmd)
(Sysval, Maketemp): Add tests of this.
* tests/options.at (--safer): Likewise.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFCiAf84KuGfSFAYARAgIlAKCF1+5QwGg+yrmLgzLV0sI4yLvuGACfYoCX
m/RL8MWDYLfsKVv5qmhWO48=
=7x/0
-END PGP SIGNATURE-
Index: doc/m4.texinfo
===
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.43
diff -u -p -r1.43 m4.texinfo
--- doc/m4.texinfo 7 Sep 2006 23:53:04 - 1.43
+++ doc/m4.texinfo 15 Sep 2006 03:30:21 -
@@ -463,6 +463,14 @@ Set the regular expression syntax accord
When this option is not given, @acronym{GNU} M4 uses emacs compatible
regular expressions. @xref{Changeresyntax}, for more details on the
format and meaning of @var{RESYNTAX-SPEC}.
+
[EMAIL PROTECTED] --safer
+Cripple the builtins @code{maketemp} (@pxref{Maketemp}),
[EMAIL PROTECTED] (@pxref{Debug Output}), @code{syscmd} (@pxref{Syscmd}),
+and @code{esyscmd} (@pxref{Esyscmd}), since they can perform potentially
+unsafe actions. An attempt to use these macros will result in an error.
+This option is intended to make it safer to preprocess an input file of
+unknown origin.
@end table
On platforms that support dynamic libraries, there are some options
@@ -2699,13 +2707,30 @@ Debug and tracing output can be redirect
@samp{-o} option to @code{m4}, or with the builtin macro @code{debugfile}:
@deffn {Builtin (gnu)} debugfile
[EMAIL PROTECTED] {Builtin (gnu)} debugfile @w{(opt @var{filename})}
-Send all further debug and trace output to @var{filename}. If
[EMAIL PROTECTED] is empty, debug and trace output are discarded and if
[EMAIL PROTECTED] is called without any arguments, debug and trace output
-are sent to the standard error output.
[EMAIL PROTECTED] {Builtin (gnu)} debugfile @w{(opt @var{file})}
+Send all further debug and trace output to @var{file}, opened in append
+mode. If @var{file} is the empty string, debug and trace output are
+discarded and if @code{debugfile} is called without any arguments, debug
+and trace output are sent to the standard error output.
+
+When the @option{--safer} option (@pxref{Invoking m4}) is in effect,
[EMAIL PROTECTED] must be empty or omitted, since otherwise an input file
+could cause the modification of arbitrary files.
@end deffn
[EMAIL PROTECTED] options: --safer
[EMAIL PROTECTED] status: 1
[EMAIL PROTECTED]
+$ @kbd{m4 --safer}
+debugfile(`foo')
[EMAIL PROTECTED]:stdin:1: debugfile: disabled by --safer
[EMAIL PROTECTED]
+debugfile()
[EMAIL PROTECTED]
+debugfile
[EMAIL PROTECTED]
[EMAIL PROTECTED] example
+
@node Input Control
@chapter Input control
@@ -4435,6 +4460,10 @@ Prior to executing the command, @code{m4
The default standard input, output and error of @var{shell-command} are
the same as those of @code{m4}.
+When the @option{--safer} option (@pxref{Invoking m4}) is in effect,
[EMAIL PROTECTED] results in an error, since otherwise an input file could
+execute arbitrary code.
+
The builtin macro @code{syscmd} is recognized only when given arguments.
@end deffn
@@ -4449,7 +4478,14 @@ syscmd(`echo foo')
Note how the expansion of @code{syscmd} keeps the trailing
Bug#385720: m4: INTERNAL ERROR: recursive push_string (fwd)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 9/4/2006 2:16 AM:
In the meantime, perhaps Autoconf should document that
all autom4te input files should always end in newline.
Nh. Let's just fix the bug in M4. It's clearly a bug.
The GNU tradition is to handle arbitrary input files,
and not to insist on text files in the POSIX sense.
OK, I found the culprit; the regression crept in on Aug 1 (post 1.4.5).
My fix to debian bug 175365 (remembering the current file and line, rather
than printing NONE:0: when diagnosing incomplete input) was not expecting
the last token in a file to be a macro expansion with no arguments. In
addition to the workaround of adding the newline, you can also fix things
by calling AC_OUTPUT with arguments (fortunately, AC_OUTPUT will ignore
those arguments, so you aren't changing the syntax of your configure.ac),
or introducing any other non-macro token (such as an empty string [],
extra whitespace, etc.). Here's the patch I'm applying, if debian wants
to release 1.4.6-2 instead of waiting for 1.4.7. And wow is it hard
adding files to the testsuite that don't end in newline, so instead I used
changequote to allow newline in a macro name to trigger a similar failure
in the 'make distcheck' testsuite, to ensure we don't regress again.
2006-09-04 Eric Blake [EMAIL PROTECTED]
* src/input.c (peek_input): Fix regression in handling macro
without arguments as last token in file; debian bug 385720.
(next_token): Always consume an input character.
Reported by Andreas Schultz.
* configure.ac (AC_INIT): Bump version number.
* NEWS: Document this fix.
* doc/m4.texinfo (History): Mention next version.
(Changeword): Add example that exposes this bug.
* THANKS: Update.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE/CkR84KuGfSFAYARAmr0AKCy6FIJDZzNWnN8nEvy7EdpJHpurQCgkHX4
VFXV6/1+nUcdhnNDrC7q93E=
=WNhB
-END PGP SIGNATURE-
Index: NEWS
===
RCS file: /sources/m4/m4/NEWS,v
retrieving revision 1.1.1.1.2.57
diff -u -p -r1.1.1.1.2.57 NEWS
--- NEWS25 Aug 2006 14:08:33 - 1.1.1.1.2.57
+++ NEWS4 Sep 2006 13:15:47 -
@@ -2,6 +2,11 @@ GNU M4 NEWS - User visible changes.
Copyright (C) 1992, 1993, 1994, 2004, 2005, 2006 Free Software
Foundation, Inc.
+Version 1.4.7 - ?? ??? 2006, by ?? (CVS version 1.4.6a)
+
+* Fix regression from 1.4.5 in handling a file that ends in a macro
+ expansion without arguments instead of a newline.
+
Version 1.4.6 - 25 August 2006, by Eric Blake (CVS version 1.4.5a)
* Fix buffer overruns in regexp and patsubst macros when handed a trailing
Index: configure.ac
===
RCS file: /sources/m4/m4/configure.ac,v
retrieving revision 1.36.2.25
diff -u -p -r1.36.2.25 configure.ac
--- configure.ac25 Aug 2006 14:08:33 - 1.36.2.25
+++ configure.ac4 Sep 2006 13:15:47 -
@@ -18,7 +18,7 @@
# 02110-1301 USA
AC_PREREQ([2.60])
-AC_INIT([GNU M4], [1.4.6], [EMAIL PROTECTED])
+AC_INIT([GNU M4], [1.4.6a], [EMAIL PROTECTED])
AM_INIT_AUTOMAKE([1.9.6 dist-bzip2 gnu])
PACKAGE=$PACKAGE_TARNAME; AC_SUBST([PACKAGE])
VERSION=$PACKAGE_VERSION; AC_SUBST([VERSION])
Index: doc/m4.texinfo
===
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.1.1.1.2.70
diff -u -p -r1.1.1.1.2.70 m4.texinfo
--- doc/m4.texinfo 24 Aug 2006 14:27:33 - 1.1.1.1.2.70
+++ doc/m4.texinfo 4 Sep 2006 13:15:48 -
@@ -360,7 +360,7 @@ addressed some long standing bugs in the
Then in 2005 Gary V. Vaughan collected together the many
patches to @acronym{GNU} @code{m4} 1.4 that were floating around the net and
released 1.4.3 and 1.4.4. And in 2006, Eric Blake joined the team and
-prepared patches for the release of 1.4.5 and 1.4.6.
+prepared patches for the release of 1.4.5, 1.4.6, and 1.4.7.
Meanwhile, development has continued on new features for @code{m4}, such
as dynamic module loading and additional builtins. When complete,
@@ -2724,6 +2724,41 @@ is a restriction on the regular expressi
@code{changeword}. This is that if your regular expression accepts
@samp{foo}, it must also accept @samp{f} and @samp{fo}.
[EMAIL PROTECTED]
+ifdef(`changeword', `', `errprint(` skipping: no changeword support
+')m4exit(`77')')dnl
+define(`foo
+', `bar
+')
[EMAIL PROTECTED]
+dnl This example wants to recognize changeword, dnl, and `foo\n'.
+dnl First, we check that our regexp will match.
+regexp(`changeword', `[cd][a-z]*\|foo[
+]')
[EMAIL PROTECTED]
+regexp(`foo
+', `[cd][a-z]*\|foo[
+]')
[EMAIL
Bug#385720: m4: INTERNAL ERROR: recursive push_string (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding autoconf to cc] According to Santiago Vila on 9/3/2006 6:55 AM: Andreas Schultz [EMAIL PROTECTED] writes: m4 crashes with m4: INTERNAL ERROR: recursive push_string Later, he adds: It seems that the problem is reproducible with every automake project that has a) AC_OUTPUT on the last line in configure.ac and b) no terminating newline on that line. Adding a newline will make the problem disappear. and in fact, I can reproduce it using GNU hello 2.1.1 by removing the last two lines of configure.ac, removing also the newline from the AC_OUTPUT final line, and then trying ./configure; make configure. This is with m4 1.4.6, and it did not happen with m4 1.4.4. Thanks for a useful bug report. I will spend time narrowing down what is causing this regression, and hope to get m4 1.4.7 out within a month, after I see if any other bugs are reported. But be advised that POSIX only requires m4 to process text files, and a file that does not end in a newline is not a text file (unless it is empty), so the bug is only triggered when you are violating POSIX. On the other hand, as a quality of implementation issue, I totally agree that this is not good practice for GNU software. In the meantime, perhaps Autoconf should document that all autom4te input files should always end in newline. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+1E984KuGfSFAYARAjmlAJ980j+ambJto90B3RnoB9CV+iJHegCeMUe3 xWN7CPNWpNOqWrL2RP4ALDE= =OhEb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96075: branch-1_4 debian bug 96075 - blind macros
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 7/31/2006 7:19 AM:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96075 complains:
format, divert and shift are all English words that
might occur in text. And they are all recognised without
arguments - the default behaviour of m4 is to make these
words disappear
However, this patch will do what you request (as well as for errprint and
m4wrap). I will need some feedback before applying this patch to 1.4.6;
otherwise, you will have to wait for m4 2.0. Plus I would need to
document the change in the .texinfo and NEWS.
I got no feedback, but decided to apply anyways. Here is the patch I used:
2006-08-15 Eric Blake [EMAIL PROTECTED]
* src/builtin.c (m4_m4wrap, m4_errprint, m4_shift): Make blind,
per debian bug 96075.
* doc/m4.texinfo (Loops, M4wrap, Errprint): Document this change.
(Changeword): Don't use shift as an example of a swallowed word.
(Divert): Discuss fact that divert is an English word.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE4dFR84KuGfSFAYARAhz9AJ92Gd4IcYuMAL3ojuWhXKCZ5WiPbwCePHUn
lomRc5wHtIkfPdI6tRunk3w=
=OCN7
-END PGP SIGNATURE-
Index: NEWS
===
RCS file: /sources/m4/m4/NEWS,v
retrieving revision 1.1.1.1.2.51
diff -u -p -r1.1.1.1.2.51 NEWS
--- NEWS9 Aug 2006 12:28:00 - 1.1.1.1.2.51
+++ NEWS15 Aug 2006 13:47:10 -
@@ -28,6 +28,8 @@ Version 1.4.6 - ?? 2006, by ?? (CVS ver
* The new macro __program__ is added, which allows the input file to issue
an error message that resembles messages from m4. Warning and error
messages have been reformatted to comply with GNU Coding Standards.
+* The errprint, m4wrap, and shift macros are now recognized only with
+ arguments.
Version 1.4.5 - 15 July 2006, by Eric Blake (CVS version 1.4.4c)
@@ -318,5 +320,6 @@ Version 0.50 - January 1990, by Rene' Se
* Initial beta release.
Local Variables:
+mode: outline
fill-column: 75
End:
Index: doc/m4.texinfo
===
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.1.1.1.2.65
diff -u -p -r1.1.1.1.2.65 m4.texinfo
--- doc/m4.texinfo 14 Aug 2006 13:07:14 - 1.1.1.1.2.65
+++ doc/m4.texinfo 15 Aug 2006 13:47:11 -
@@ -903,7 +903,8 @@ call is not triggered. This solves the
specific provision.
There is also a command line option (@option{--prefix-builtins}, or
[EMAIL PROTECTED]) which requires all builtin macro names to be prefixed
[EMAIL PROTECTED], @pxref{Invoking m4}) which requires all builtin macro names
+to be prefixed
by @samp{m4_} for them to be recognized. The option has no effect
whatsoever on user defined macros. For example, with this option,
one has to write @code{m4_dnl} and even @code{m4_m4exit}.
@@ -1010,8 +1011,8 @@ there are too many arguments, the excess
Normally @code{m4} will issue warnings if a builtin macro is called
with an inappropriate number of arguments, but it can be suppressed with
-the @option{-Q} command line option. For user defined macros, there is no
-check of the number of arguments given.
+the @option{-Q} command line option (@pxref{Invoking m4}). For user
+defined macros, there is no check of the number of arguments given.
Macros are expanded normally during argument collection, and whatever
commas, quotes and parentheses that might show up in the resulting
@@ -1847,11 +1848,13 @@ be used for iterating through the actual
@deffn Builtin shift (@dots{})
Takes any number of arguments, and expands to all but the first
argument, separated by commas, with each argument quoted.
+
+The macro @code{shift} is recognized only with parameters.
@end deffn
@example
shift
[EMAIL PROTECTED]
[EMAIL PROTECTED]
shift(`bar')
@result{}
shift(`foo', `bar', `baz')
@@ -2061,7 +2064,7 @@ The number between dashes is the depth o
of the time, signifying an expansion at the outermost level, but it
increases when macro arguments contain unquoted macro calls. The
maximum number that will appear between dashes is controlled by the
-option @option{--nesting-limit}.
+option @option{--nesting-limit} (@pxref{Invoking m4}).
Tracing by name is an attribute that is preserved whether the macro is
defined or not. This allows the @option{-t} option to select macros to
@@ -2123,8 +2126,9 @@ display.
@cindex controlling debugging output
@cindex debugging output, controlling
-The @option{-d} option to @code{m4} controls the amount of details
-presented, when using the macros described in the preceding sections.
+The @option{-d} option to @code{m4} (@pxref{Invoking m4}) controls the
+amount of details
Bug#175365: branch-1_4 debian bug 175365 - line NONE:0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=175365 complains about
$ m4 file.m4
...
NONE:0: m4: ERROR: EOF in argument list
why can't it make error lines with filename and line number so we can
jump to them in emacs' compile mode?
Fixing this for m4wrap is prohibitive for the branch (see
http://lists.gnu.org/archive/html/m4-patches/2006-07/msg00079.html), but I
hope to get it done before m4 2.0. But m4wrap tends to be less of a
problem for generating dangling input.
Fixing it for EOF in argument list, string, or comment should be done per
the patch below. It was more difficult than what was attempted several
years ago on CVS head:
http://cvs.savannah.gnu.org/viewcvs/m4/m4/input.c?root=m4r1=1.19r2=1.20
Oops - valgrind won't normally catch the memory bug in revision 1.20 of
input.c, thanks to obstacks being so generous. But saving m4_current_file
(which points to storage on the current_input obstack), then using it
after the obstack has been shrunk in pop_input, is asking for problems, on
the rare corner cases where you can coerce obstack_free to free the
storage used by m4_current_file (such as if the input filename was more
than an obstack_chunk in size). So I will have to port this patch to CVS
head before m4 2.0 is released.
2006-08-01 Eric Blake [EMAIL PROTECTED]
* src/input.c (skip_line, next_token): Remember current file in
case input file ends abruptly. Addresses debian bug 175365.
(pop_input): Defer freeing storage that holds previous file
name...
(pop_wrapup): to here, after error message is issued.
* src/macro.c (expand_argument): Remember current file in case
input file ends abruptly.
* doc/m4.texinfo (Macro Arguments, Dnl, Changequote, Changecom)
(M4wrap): Adjust testsuite accordingly.
(Errprint): Document line number limitation of m4wrap.
* NEWS: Document this fix.
* THANKS: Update.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEz1GG84KuGfSFAYARAlRFAJ9pzXYYfYtOvQ3NDWYC+jDCj7B7vgCghx0Y
7h3aUNpBKoYUBAY/SrQfHS0=
=VQ+f
-END PGP SIGNATURE-
Index: NEWS
===
RCS file: /sources/m4/m4/NEWS,v
retrieving revision 1.1.1.1.2.46
diff -u -p -r1.1.1.1.2.46 NEWS
--- NEWS1 Aug 2006 02:53:35 - 1.1.1.1.2.46
+++ NEWS1 Aug 2006 13:02:08 -
@@ -17,6 +17,8 @@ Version 1.4.6 - ?? 2006, by ?? (CVS ver
collection.
* The dnl macro now warns if end of file is encountered instead of a
newline.
+* The error message when end of file is encountered now uses the file where
+ the dangling construct started, rather than NONE:0.
* The __file__ macro, and the -s/--synclines option, now show what
directory a file was found in when the -I/--include option or M4PATH
variable had an effect.
Index: doc/m4.texinfo
===
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.1.1.1.2.58
diff -u -p -r1.1.1.1.2.58 m4.texinfo
--- doc/m4.texinfo 1 Aug 2006 02:53:35 - 1.1.1.1.2.58
+++ doc/m4.texinfo 1 Aug 2006 13:02:09 -
@@ -1043,10 +1043,9 @@ It is an error if the end of file occurs
@example
define(
^D
[EMAIL PROTECTED]:0: m4: ERROR: end of file in argument list
[EMAIL PROTECTED]:stdin:1: ERROR: end of file in argument list
@end example
-
@node Quoting Arguments
@section Quoting macro arguments
@@ -2317,7 +2316,7 @@ m4wrap(`m4wrap(`2 hi
')0 hi dnl 1 hi')
@result{}
^D
[EMAIL PROTECTED]:0: m4: Warning: end of file treated as newline
[EMAIL PROTECTED]:NONE:0: Warning: end of file treated as newline
@result{}0 HI 2 HI
@end example
@@ -2454,7 +2453,7 @@ It is an error if the end of file occurs
@example
`dangling quote
^D
[EMAIL PROTECTED]:0: m4: ERROR: end of file in string
[EMAIL PROTECTED]:stdin:1: ERROR: end of file in string
@end example
@node Changecom
@@ -2551,7 +2550,7 @@ changecom(`/*', `*/')
@result{}
/*dangling comment
^D
[EMAIL PROTECTED]:0: m4: ERROR: end of file in comment
[EMAIL PROTECTED]:stdin:1: ERROR: end of file in comment
@end example
@node Changeword
@@ -2778,7 +2777,7 @@ file condition between two input files.
m4wrap(`m4wrap(`)')len(abc')
@result{}
^D
[EMAIL PROTECTED]:0: m4: ERROR: end of file in argument list
[EMAIL PROTECTED]:NONE:0: ERROR: end of file in argument list
@end example
@node File Inclusion
@@ -4054,6 +4053,11 @@ include(`incl.m4')
@result{}
@end example
+Currently, all text wrapped with @code{m4wrap} (@pxref{M4wrap}) behaves
+as though it came from line 0 of the file ``NONE''. It is hoped that a
+future release of @code{m4} can overcome this limitation and remember
Bug#96075: branch-1_4 debian bug 96075 - blind macros
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96075 complains:
format, divert and shift are all English words that
might occur in text. And they are all recognised without
arguments - the default behaviour of m4 is to make these
words disappear
format is a GNU extension, and as such, I already made it blind (along
with indir) in m4 1.4.5.
divert is required by POSIX to accept 0 arguments as shorthand for
divert(0). The best I can do is to document this; however, I did add
words to the 1.4.5 documentation to the effect that you can make any macro
blind by yourself:
define(`divert', `ifelse(`$#', `0', ``$0'', `builtin(`$0', $@)')')
You can also use the -P/--prefix-builtins command line option to put all
builtins in the m4_ namespace, so they don't clash with English
words/shell keywords.
That leaves shift. I previously asked whether this should be changed now
or wait for m4 2.0, and the decision for 1.4.5 was to leave status quo
alone: http://lists.gnu.org/archive/html/bug-m4/2006-07/msg2.html
However, this patch will do what you request (as well as for errprint and
m4wrap). I will need some feedback before applying this patch to 1.4.6;
otherwise, you will have to wait for m4 2.0. Plus I would need to
document the change in the .texinfo and NEWS.
2006-07-31 Eric Blake [EMAIL PROTECTED]
* src/builtin.c (m4_errprint, m4_m4wrap, m4_shift): Make blind,
per debian bug 96075.
* doc/m4.texinfo (Loops): Adjust test accordingly.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEzgNn84KuGfSFAYARAmxNAJ9ksrlDnL6J72lyMQOvnZeU1ZZEgQCgyzKW
THIJsqWIoo2rKuScUicT2r0=
=LJ8n
-END PGP SIGNATURE-
Index: doc/m4.texinfo
===
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.1.1.1.2.56
diff -u -p -r1.1.1.1.2.56 m4.texinfo
--- doc/m4.texinfo 30 Jul 2006 21:46:10 - 1.1.1.1.2.56
+++ doc/m4.texinfo 31 Jul 2006 13:15:21 -
@@ -1842,7 +1842,7 @@ argument, separated by commas, with each
@example
shift
[EMAIL PROTECTED]
[EMAIL PROTECTED]
shift(`bar')
@result{}
shift(`foo', `bar', `baz')
Index: src/builtin.c
===
RCS file: /sources/m4/m4/src/Attic/builtin.c,v
retrieving revision 1.1.1.1.2.30
diff -u -p -r1.1.1.1.2.30 builtin.c
--- src/builtin.c 30 Jul 2006 23:46:51 - 1.1.1.1.2.30
+++ src/builtin.c 31 Jul 2006 13:15:21 -
@@ -112,7 +112,7 @@ builtin_tab[] =
{ divnum, FALSE, FALSE, FALSE, m4_divnum },
{ dnl, FALSE, FALSE, FALSE, m4_dnl },
{ dumpdef, FALSE, FALSE, FALSE, m4_dumpdef },
- { errprint,FALSE, FALSE, FALSE, m4_errprint },
+ { errprint,FALSE, FALSE, TRUE, m4_errprint },
{ esyscmd, TRUE, FALSE, TRUE, m4_esyscmd },
{ eval,FALSE, FALSE, TRUE, m4_eval },
{ format, TRUE, FALSE, TRUE, m4_format },
@@ -124,13 +124,13 @@ builtin_tab[] =
{ indir, TRUE, FALSE, TRUE, m4_indir },
{ len, FALSE, FALSE, TRUE, m4_len },
{ m4exit, FALSE, FALSE, FALSE, m4_m4exit },
- { m4wrap, FALSE, FALSE, FALSE, m4_m4wrap },
+ { m4wrap, FALSE, FALSE, TRUE, m4_m4wrap },
{ maketemp,FALSE, FALSE, TRUE, m4_maketemp },
{ patsubst,TRUE, FALSE, TRUE, m4_patsubst },
{ popdef, FALSE, FALSE, TRUE, m4_popdef },
{ pushdef, FALSE, TRUE, TRUE, m4_pushdef },
{ regexp, TRUE, FALSE, TRUE, m4_regexp },
- { shift, FALSE, FALSE, FALSE, m4_shift },
+ { shift, FALSE, FALSE, TRUE, m4_shift },
{ sinclude,FALSE, FALSE, TRUE, m4_sinclude },
{ substr, FALSE, FALSE, TRUE, m4_substr },
{ syscmd, FALSE, FALSE, TRUE, m4_syscmd },
@@ -1088,6 +1088,8 @@ m4_dnl (struct obstack *obs, int argc, t
static void
m4_shift (struct obstack *obs, int argc, token_data **argv)
{
+ if (bad_argc (argv[0], argc, 2, -1))
+return;
dump_args (obs, argc - 1, argv + 1, ,, TRUE);
}
@@ -1223,8 +1225,11 @@ m4_maketemp (struct obstack *obs, int ar
static void
m4_errprint (struct obstack *obs, int argc, token_data **argv)
{
+ if (bad_argc (argv[0], argc, 2, -1))
+return;
dump_args (obs, argc, argv, , FALSE);
obstack_1grow (obs, '\0');
+ debug_flush_files ();
fprintf (stderr, %s, (char *) obstack_finish (obs));
fflush (stderr);
}
@@ -1294,6 +1299,8 @@ m4_m4exit (struct obstack *obs, int argc
static void
m4_m4wrap (struct obstack *obs, int argc, token_data **argv
Bug#311378: branch-1_4 debian bug 311378 - 8-bit quotes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311378 complains:
$ m4 samp1 EOF
changequote(«,»)dnl
define(a,b)dnl
«a»
EOF
«b»
And indeed, on platforms where char is signed, we had some sign extension
bugs, since we were comparing getc()'s unsigned chars vs a char*. With
this patch, m4 should now be 8-bit clean; I went the path of always using
unsigned char in the parser.
Unfortunately, I don't know any good way to put an example of 8-bit
characters in the documentation. Info will faithfully reproduce literal
characters (but it may render horribly depending on your local), while TeX
ignores 8-bit characters and needs a command for a glyph. So for now, I
left the examples in an @ignore block, so at least the testsuite will
ensure we don't regress.
2006-07-31 Eric Blake [EMAIL PROTECTED]
* src/input.c (peek_input, next_char, match_input): Be eight-bit
clean; fixes debian bug 311378.
* doc/m4.texinfo (Syntax): Describe eight-bit handling.
(Changequote, Changecom): Add examples to test this.
* NEWS: Document this fix.
* THANKS: Update.
Reported by Steven Augart.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEzsIb84KuGfSFAYARAjV6AKC4F7Y2rpNKr8LzY8Murz2fnAy01gCfY4pv
adcorwShehrSo21KhbyPdvg=
=dSGW
-END PGP SIGNATURE-
Index: NEWS
===
RCS file: /sources/m4/m4/NEWS,v
retrieving revision 1.1.1.1.2.45
diff -u -p -r1.1.1.1.2.45 NEWS
--- NEWS30 Jul 2006 03:18:12 - 1.1.1.1.2.45
+++ NEWS1 Aug 2006 02:44:33 -
@@ -20,6 +20,7 @@ Version 1.4.6 - ?? 2006, by ?? (CVS ver
* The __file__ macro, and the -s/--synclines option, now show what
directory a file was found in when the -I/--include option or M4PATH
variable had an effect.
+* The changequote and changecom macros now work with 8-bit characters.
Version 1.4.5 - 15 July 2006, by Eric Blake (CVS version 1.4.4c)
Index: src/input.c
===
RCS file: /sources/m4/m4/src/Attic/input.c,v
retrieving revision 1.1.1.1.2.13
diff -u -p -r1.1.1.1.2.13 input.c
--- src/input.c 30 Jul 2006 23:46:51 - 1.1.1.1.2.13
+++ src/input.c 1 Aug 2006 02:44:33 -
@@ -397,7 +397,7 @@ init_macro_token (token_data *td)
int
peek_input (void)
{
- register int ch;
+ int ch;
while (1)
{
@@ -407,7 +407,7 @@ peek_input (void)
switch (isp-type)
{
case INPUT_STRING:
- ch = isp-u.u_s.string[0];
+ ch = to_uchar (isp-u.u_s.string[0]);
if (ch != '\0')
return ch;
break;
@@ -446,13 +446,13 @@ peek_input (void)
#define next_char() \
(isp isp-type == INPUT_STRING isp-u.u_s.string[0]\
- ? *isp-u.u_s.string++ \
+ ? to_uchar (*isp-u.u_s.string++) \
: next_char_1 ())
static int
next_char_1 (void)
{
- register int ch;
+ int ch;
if (start_of_input_line)
{
@@ -468,7 +468,7 @@ next_char_1 (void)
switch (isp-type)
{
case INPUT_STRING:
- ch = *isp-u.u_s.string++;
+ ch = to_uchar (*isp-u.u_s.string++);
if (ch != '\0')
return ch;
break;
@@ -531,14 +531,14 @@ match_input (const char *s)
const char *t;
ch = peek_input ();
- if (ch != *s)
+ if (ch != to_uchar (*s))
return 0; /* fail */
(void) next_char ();
if (s[1] == '\0')
return 1; /* short match */
- for (n = 1, t = s++; (ch = peek_input ()) == *s++; n++)
+ for (n = 1, t = s++; (ch = peek_input ()) == to_uchar (*s++); n++)
{
(void) next_char ();
if (*s == '\0') /* long match */
@@ -564,9 +564,9 @@ match_input (const char *s)
`*/
#define MATCH(ch, s) \
- ((s)[0] == (ch) \
-(ch) != '\0' \
-((s)[1] == '\0' \
+ (to_uchar ((s)[0]) == (ch)\
+(ch) != '\0' \
+((s)[1] == '\0' \
|| (match_input ((s) + 1) ? (ch) = peek_input (), 1 : 0)))
Index: doc/m4.texinfo
===
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.1.1.1.2.57
diff -u -p -r1.1.1.1.2.57 m4.texinfo
--- doc/m4.texinfo 31 Jul 2006 20:28:12 - 1.1.1.1.2.57
+++ doc/m4.texinfo 1 Aug 2006 02:44:34 -
@@ -698,8 +698,12 @@ primitive is spelled within @code{m4}.
As @code{m4} reads its input
Bug#5898: debian bug 5898 - security option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5898 Yes, you read that right - an open bug with only a 4-digit ID. 9 years and 236 days old. There should be an option to disable `dangerous' operations like writing files and executing programs, and another to disable reading files too. Dangerous builtins include (according to the Info page): debugfile syscmd esyscmd sysval maketemp File reading builtins include: include sinclude The idea might be nice for m4 2.0, but is not worth adding to the 1.4.x branch. My take on what a --secure option would disable: debugfile (it can overwrite arbitrary existing files) syscmd (it invokes arbitrary shell commands) esyscmd (likewise) maketemp (invoked enough times, it can form a denial-of-service by creating lots of files) builtin (at least, builtin on any of the restricted commands) However, I see no reason to disable sysval (although it always results in 0 if you don't have [e]syscmd). And I don't see how reading files can be a security issue, since the person executing m4 can read those files from the command line in the first place, so include, sinclude, and undivert should remain active. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzsTL84KuGfSFAYARAphRAJ4vPiWem6LKdqKRYUi7OyuXMahLAwCeIA/Z TgzRqi3Kgx70As5MvgHa9t8= =z4Ic -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#53685: branch-1_4 - debian bug 53685: -s -I bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When an include file is found not in the current directory, but in
one of the -I directories (or through an env var), the #line
directives must include the full path (like cpp does).
Agreed. It also affects the __file__ macro. Here's a patch that will
make it in 1.4.6 that does just that:
2006-07-29 Eric Blake [EMAIL PROTECTED]
* src/path.c (path_search): Add result parameter, so that
-I can be accounted for. Debian bug 53685.
* src/m4.h (path_search): Update prototype.
* src/m4.c (main): Adjust callers.
* src/freeze.c (reload_frozen_state): Likewise.
* src/builtin.c (include, m4_undivert): Likewise.
* NEWS: Document this change.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEzCTH84KuGfSFAYARAn1HAJwJw3zlxiCUyH7xIfYjJMVU3QqOcwCeNTeW
mTgjRWLhu7xEzAe7P91cfFI=
=qg0L
-END PGP SIGNATURE-
Index: NEWS
===
RCS file: /sources/m4/m4/NEWS,v
retrieving revision 1.1.1.1.2.44
diff -u -p -r1.1.1.1.2.44 NEWS
--- NEWS26 Jul 2006 23:21:29 - 1.1.1.1.2.44
+++ NEWS30 Jul 2006 03:15:36 -
@@ -17,6 +17,9 @@ Version 1.4.6 - ?? 2006, by ?? (CVS ver
collection.
* The dnl macro now warns if end of file is encountered instead of a
newline.
+* The __file__ macro, and the -s/--synclines option, now show what
+ directory a file was found in when the -I/--include option or M4PATH
+ variable had an effect.
Version 1.4.5 - 15 July 2006, by Eric Blake (CVS version 1.4.4c)
Index: src/builtin.c
===
RCS file: /sources/m4/m4/src/Attic/builtin.c,v
retrieving revision 1.1.1.1.2.28
diff -u -p -r1.1.1.1.2.28 builtin.c
--- src/builtin.c 27 Jul 2006 21:41:12 - 1.1.1.1.2.28
+++ src/builtin.c 30 Jul 2006 03:15:37 -
@@ -1049,7 +1049,7 @@ m4_undivert (struct obstack *obs, int ar
non-numeric argument to builtin `%s', ARG (0)));
else
{
- fp = path_search (ARG (i));
+ fp = path_search (ARG (i), NULL);
if (fp != NULL)
{
insert_file (fp);
@@ -1154,11 +1154,12 @@ static void
include (int argc, token_data **argv, boolean silent)
{
FILE *fp;
+ const char *name;
if (bad_argc (argv[0], argc, 2, 2))
return;
- fp = path_search (ARG (1));
+ fp = path_search (ARG (1), name);
if (fp == NULL)
{
if (!silent)
@@ -1167,7 +1168,8 @@ include (int argc, token_data **argv, bo
return;
}
- push_file (fp, ARG (1));
+ push_file (fp, name);
+ free ((char *) name);
}
/*.
Index: src/freeze.c
===
RCS file: /sources/m4/m4/src/freeze.c,v
retrieving revision 1.1.1.1.2.11
diff -u -p -r1.1.1.1.2.11 freeze.c
--- src/freeze.c24 Jul 2006 20:02:16 - 1.1.1.1.2.11
+++ src/freeze.c30 Jul 2006 03:15:37 -
@@ -222,7 +222,7 @@ reload_frozen_state (const char *name)
} \
while (character == '\n')
- file = path_search (name);
+ file = path_search (name, NULL);
if (file == NULL)
M4ERROR ((EXIT_FAILURE, errno, cannot open %s, name));
Index: src/m4.c
===
RCS file: /sources/m4/m4/src/Attic/m4.c,v
retrieving revision 1.1.1.1.2.22
diff -u -p -r1.1.1.1.2.22 m4.c
--- src/m4.c27 Jul 2006 18:12:08 - 1.1.1.1.2.22
+++ src/m4.c30 Jul 2006 03:15:37 -
@@ -503,7 +503,8 @@ Written by Rene' Seindal.\n\
push_file (stdin, stdin);
else
{
- fp = path_search (argv[optind]);
+ const char *name;
+ fp = path_search (argv[optind], name);
if (fp == NULL)
{
error (0, errno, %s, argv[optind]);
@@ -512,8 +513,8 @@ Written by Rene' Seindal.\n\
retcode = EXIT_FAILURE;
continue;
}
- else
- push_file (fp, argv[optind]);
+ push_file (fp, name);
+ free ((char *) name);
}
expand_input ();
}
Index: src/m4.h
===
RCS file: /sources/m4/m4/src/m4.h,v
retrieving revision 1.1.1.1.2.21
diff -u -p -r1.1.1.1.2.21 m4.h
--- src/m4.h28 Jul 2006 20:39:37 - 1.1.1.1.2.21
+++ src/m4.h30 Jul 2006 03:15:37 -
@@ -398,7 +398,7 @@ const builtin *find_builtin_by_name (con
void include_init (void);
void include_env_init (void);
void add_include_directory (const char
Bug#369822: ls -i stats unnecessarily
I can understand why readdir might have the behavior that you describe: it might be more efficient internally. But that doesn't make it correct, or even expected. It's a bug in readdir. I agree - readdir should ALWAYS match stat, even in the face of mount points, if it is going to provide d_ino. Even cygwin developers took great care in their upcoming 1.5.20 release to ensure that mount points are handled correctly, such that readdir reports the same value that stat will provide. Is there an easy configure or runtime test we can do to detect buggy readdir implementations, and always do stat on those platforms? -- Eric Blake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368012: mingw crosscompilation broken with autoconf-2.59.cvs.2006.05.13-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralf, According to Ralf Wildenhues on 5/25/2006 4:49 AM: 2006-05-25 Stepan Kasal [EMAIL PROTECTED] and Ralf Wildenhues [EMAIL PROTECTED] * lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_DEFAULT): Drop the initialization of `ac_cv_exeext', do not override it if it was already set, unless it was set to `no', for compatibility with Autoconf-2.13, and comment this. Do not export `ac_cv_exeext', Libtool hasn't needed this for years. (_AC_COMPILER_EXEEXT_DEFAULT): Likewise, do not export it. (_AC_COMPILER_EXEEXT_WORKS, _AC_COMPILER_EXEEXT_CROSS): Typos. * doc/autoconf.texi (Compilers and Preprocessors) EXEEXT: Document that this test may be overridden by setting `ac_cv_exeext'. --- lib/autoconf/lang.m4 2006-05-25 12:45:55.0 +0200 +++ lib/autoconf/lang.m4 2006-05-25 12:42:36.0 +0200 @@ -495,9 +495,11 @@ rm -f $ac_rmfiles AS_IF([AC_TRY_EVAL(ac_link_default)], -[# Be careful to initialize this variable, since it used to be cached. -# Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile. -ac_cv_exeext= +[# Autoconf-2.13 could set the ac_cv_exeext variable to `no'. +# So ignore a value of `no', otherwise this would lead to `EXEEXT = no' +# in a Makefile. Because we should not override ac_cv_exeext if it was +# cached, so that the user can short-circuit this test for compilers +# unknown to Autoconf. That last sentence needs help. I would s/Because we/We/. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdafM84KuGfSFAYARAoCrAJ94cgrU6rkY9hhLBQpzRhuuE5r+ugCePY88 q2+QLeE7L5KMlJWy7NgMARs= =zMV6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354875: /bin/cp directory full vs. disk full messages
According to Dan Jacobson on 2/28/2006 10:44 PM: Version: 5.93-5 The latest stable version is 5.94 - consider upgrading. Separate directory full from disk full when giving messages to the user, else he might never guess the solution. This would require support from the kernel - coreutils is just faithfully printing the error string associated with ENOSPC, which is unfortunately the same error returned by the kernel whether the directory or the disk is full. Maybe historically for UNIX this would never happen, so the messages were never improved. Correct - FAT is one of the few filesystems where the root directory is inherently limited in the number of files it can contain; normal Unix filesystems can use as many inodes in any directory as the device contains. In other words, a directory is normally never full unless the disk has no spare inodes anywhere, whereas in your case, you could still create files in an existing subdirectory, just not in the root directory. Also, be aware that even on traditional Unix filesystems it is possible to consume all of a device's inodes while still having spare space (existing files can grow, but no new files created), or to consume all the non-inode space while still having spare inodes (existing files can't grow beyond their current block size, but it may be possible to create empty files). In other words, a no space left error message is about as accurate as you can get. In my mind, it is unfortunate that FAT was chosen as the filesystem of choice for flash drives, since FAT cannot preserve file permissions. -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325205: please provide sha256sum, sha384sum and sha512sum
Can I ask you to take a look at the attached patch? It is not yet satisfactory (at least, it needs to be forwardported to the CVS version, as I worked against 5.2.1 because I wanted to install this ASAP on my Debian boxen), but maybe we can start from this to discuss what needs to be done. It implements sha224, sha256, sha384 and sha512. Would it make more sense to have a single sha utility that takes an argument of which algorithm to use, defaulting to the most secure, then the user can define wrappers to invoke a non-default algorithm? For example, 'sha --algorithm=sha224' or 'sha --224'? -- Eric Blake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#160849: coreutils: bug report for GNU Core Utils
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/24/2005 1:58 AM:
Now, the help output for --reply looks like this:
--reply={yes,no,query} specify how to handle the prompt about an
existing destination file. Note that
--reply=no has an effect only when mv
would prompt without -i or equivalent, i.e.,
when a destination file exists and is not
writable, standard input is a terminal, and
no -f (or equivalent) option is specified
That wording is a bit awkward. How about this instead:
Note that --reply=no has an effect only when mv would prompt, either when
- -i is present, or for the combination of a destination file exists, is not
writable, standard input is a terminal, and -f (or equivalent) is not present
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCu/tp84KuGfSFAYARApSsAKCiKnapvQ/B7MTScZaiWEFDGJ2uiQCfUfwA
fU+r5LMJxtCYtnjA7hC5dX8=
=JiDj
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
