Bug#500501: sed silently ignores invalid multibyte sequences on input stream
Hello, The sed manual has been expanded to discuss locale and invalid multybyte sequences, incorporating some details from this thread. See: https://git.savannah.gnu.org/cgit/sed.git/commit/?id=05800ee0b7 regards, - assaf
Bug#832088: sed: silently fails with -n option specified first
Hello, Paolo Bonzini wrote: On 22/07/2016 09:02, Daniel Iancu wrote: sed -ni 's/foo/bar/' test # fails So this is not a bug. I've expanded sed's manual to mention this specific issue: https://git.savannah.gnu.org/cgit/sed.git/commit/?id=a36e8abccc5db38e4d2f8ea2bbb3e78dfddacd78 regards, - assaf
Bug#284646: sed: Documentation does not properly document effects of multiple commands
Hello, - it is not specified whether address selections following a command act on unchanged input lines [...] or on the lines as changed by the previous command I've clarified this point in sed's manual and man-page: https://git.savannah.gnu.org/cgit/sed.git/commit/?id=de6b6ccd7400b6483ecee5eebc7d48666b497680 regards, - assaf
Bug#605142: sed: incorrectly interprets \x hexadecimal escapes sometimes
Hello, I've added a paragraph about the current behavior with your example to sed's manual: https://git.savannah.gnu.org/cgit/sed.git/commit/?id=a805d57e1f6427b55 regards, - assaf
Bug#281639: sed's documentation is non-free
Hello, If it helps in any way, the documentation in sed-4.4 (included in 'stretch') as licensed under GFDLv1.3 and explicitly states: "with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts." http://git.savannah.gnu.org/cgit/sed.git/tree/doc/sed.texi#n39 regards, - assaf
Bug#466862: sed: documentation bug: no mention of semicolon as command terminator
Hello, Panu Kalliokoski wrote: However, the possibility of using semicolons in not mentioned on sed's man page nor in its info document. Instead, both insist that every command must be on its own line. There's now a dedicated section in gnu sed's manual about multiple commands and semicolons: https://www.gnu.org/software/sed/manual/html_node/Multiple-commands-syntax.html#Multiple-commands-syntax It is included in the texinfo file of sed-4.4 (which is now in 'testing'). regards, - assaf
Bug#284646: sed: Documentation does not properly document effects of multiple commands
Hello, - Usage of multiple commands [...] - The possibility to use a semicolon instead of a newline [...] 12 years later, there's now a dedicated section in gnu sed's manual about multiple commands and semicolons: https://www.gnu.org/software/sed/manual/html_node/Multiple-commands-syntax.html#Multiple-commands-syntax It is included in the texinfo file of sed-4.4 (which is now in 'testing'). - it is not specified whether address selections following a command act on unchanged input lines [...] or on the lines as changed by the previous command That's a good point. The 'address' section is much expanded: https://www.gnu.org/software/sed/manual/html_node/sed-addresses.html#sed-addresses But I'll add explicit mention of this issue. regards, - assaf
Bug#605142: sed: incorrectly interprets \x hexadecimal escapes sometimes
Hello, Picking up an old sed bug: Matija Nalis wrote: echo 'a^c' | sed -e 's/\x5e/b/' should produce output "abc" (as it does in "ssed" or "perl -pe"), but in GNU sed it produces "ba^c". I agree this is indeed GNU sed's behavior, but it's not clear it is incorrect behavior (or if there is a correct one). GNU sed internally converts escape seqeunces to their corresponding characters *before* passing it on to glibc's regex engine (or doing other operations). It is glibc's regex that does not support unescaping, which is why this is needed. Few additional cases: Un-escaping works in other sed commands: $ echo 'a^c' | sed 'y/\x5e/b/' abc And gnu grep, which doesn't unescape, passes the string to the regex engine, which then doesn't match at all: $ echo 'a^c' | gnu-grep-2.26 '\x5e' As opposed to freebsd's grep: $ echo 'a^c' | freebsd-grep-2.5.1 '\x5e' a^c Many other sed implementations don't support unescaping at all, and return: $ echo 'a^c' | sed 's/\x5e/b/' a^c $ echo 'a^c' | sed 'y/\x5e/b/' sed: 1: "y/\x5e/b/": transform strings are not the same length This is the case for sed from FreeBSD, OpenBSD, BusyBox, ToyBox. Lastly, POSIX does not mention anything about '\xXX' escape sequences, so this is left to implementors to decide. As such, I would suggest marking #605142 as notabug and closing it. I will add some info about it to sed's manual. If someone wants to suggest this as a new feature, please write to sed-de...@gnu.org . However since this breaks existing behavior, the bar to accepting it might be high. regards, - assaf
Bug#853864: sed-4.4 released (with bugfix)
Hello, sed-4.4 with the segfault bugfix has been released: https://lists.gnu.org/archive/html/info-gnu/2017-02/msg1.html Available here: https://ftp.gnu.org/gnu/sed/sed-4.4.tar.xz regards, - assaf
Bug#853864: sed-4.3 in 'stretch' can segfault - planned upgrade
Package: sed Version: 4.3-3 Severity: serious Hello, My name is Assaf, I'm a new co-maintainer of GNU Sed. I'm writing to you about updates to 'sed-4.3' for the coming 'stretch' release. A bug was discovered in sed-4.3 which can lead to a segfault. We're working on releasing a bugfix release very soon: https://lists.gnu.org/archive/html/sed-devel/2017-01/msg00027.html Full details are here: https://bugs.gnu.org/25390 Fixed in these commits: http://git.savannah.gnu.org/cgit/sed.git/commit/?id=44d99bf5c98 http://git.savannah.gnu.org/cgit/sed.git/commit/?id=0f98f0055e4 The fix involves updates to the underlying gnulib library, and I suspect backporting it won't be trivial (and will cause more work for you upstream). I understand this is very close to the 'freeze', but I think it would be worth upgrading. I'll update this ticket once it's released. The release-candidate is: http://meyering.net/sed/sed-4.3.20-e9ab.tar.xz Please let us know if we can help with anything. regards, - assaf
Bug#779885: info: Does not display a info-file from the start, if it contains (some) multibyte characters
Hello, On 06/06/2015 06:13 AM, Gavin Smith wrote: Looking at the dir file you attached, there are the following entries: * Coreutils: (coreutils). Core GNU (file, text, shell) utilities. * coreutils: (coreutils)coreutils invocation. Multi-call program. The two labels are Coreutils and coreutils. Info prefers an exact case match, so it will display (coreutils)coreutils invocation. Info is operating as expected here. The problem is with the Info file - it was a bad idea to add that dir entry. I could be wrong, but I think this issue has already been fixed in the coreutils' git repository (though after 8.23 was released): http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18428 http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=72e470b9b5af77bcfd90ac175ed285877837ba20 -assaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760861: bug#18428: Bug#760861: bug#18428: Bug#760861: bug#18428: coreutils binary breaks coreutils documentation
On 09/09/2014 10:52 AM, Michael Stone wrote: On Tue, Sep 09, 2014 at 03:31:35PM +0100, Pádraig Brady wrote: It's useful to many, but I agree most don't bother with it due to the awkward non intuitive default info reader _interface_ (though pinfo is a bit better in that regard). Right. I've heard the argument for 15 years that info docs are really good, it's just the interface. :) In all that time, a better interface hasn't really caught on, and the web happened. Though it would be better to have direct links. Now the above full node URL is too long/awkward, so I've just now setup redirects, so the following proposed new trailers for ls --help and man pages should work: ls --help: ... Full documentation online at: http://www.gnu.org/software/coreutils/ls Full installed documentation: info '(coreutils) ls invocation' A huge improvement. I suspect that this might also help the info docs show up in google, instead of being below the fold. Alternative wording: Full documentation online at: http://www.gnu.org/software/coreutils/ls or available locally via: info '(coreutils) ls invocation' BTW, http://gnu.org/s/; redirects to http://www.gnu.org/software/; , so http://gnu.org/s/coreutils/ls also works. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667161: [Debian-med-packaging] Bug#667161: FASTX-Toolkit faisl to build with GCC-4.7.
Hello Charles, The updated versions (libgtextutils 0.6.1 and fastx-toolkit 0.0.13.2) are now available for download: http://hannonlab.cshl.edu/fastx_toolkit/download.html Sorry for the delayed release. Regards, -gordon Charles Plessy wrote, On 04/14/2012 11:08 PM: Le Thu, Apr 12, 2012 at 04:21:29PM -0400, Assaf Gordon a écrit : I've created a new tarball which explicitly includes unistd.h in the relevant CPP files - may I ask you to test it ? http://cancan.cshl.edu/labmembers/gordon/files/fastx_toolkit-0.0.13.2--20120412-1613.tar.bz2 Hello Gordon, thanks for the update. It build find with GCC-4.7 on my system. Please let me know when you release 0.0.13.2. Have a nice Sunday, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667161: FASTX-Toolkit faisl to build with GCC-4.7.
Hello Charles, Charles Plessy wrote, On 04/04/2012 12:17 AM: Debian distributes FASTX-Toolkit, and after a mass-rebuild against GCC 4.7, we noticed the following error: ../libfastx/sequence_alignment.h:146:32: error: 'ssize_t' does not name a type I can't reproduce it locally (don't have Ubuntu with GCC-4.7 yet), but after reading the porting guide, I'm guessing this error stems from re-organization done in GCC-4.7 which removed unistd.h from some header files. I've created a new tarball which explicitly includes unistd.h in the relevant CPP files - may I ask you to test it ? http://cancan.cshl.edu/labmembers/gordon/files/fastx_toolkit-0.0.13.2--20120412-1613.tar.bz2 Thanks, -gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626757: libgtextutils: Ignored return value caused build failure when warn_unused_result is error.
Hello Charles, Charles Plessy wrote, On 05/21/2011 04:28 AM: It still fails to build on Ubuntu, with the error I silenced with the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626757#5 Please try this new version, available here: http://hannonlab.cshl.edu/fastx_toolkit/libgtextutils-0.6.2.tar.bz2 Thanks, -gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626757: libgtextutils: Ignored return value caused build failure when warn_unused_result is error.
Charles, I've put a fixed version here: http://hannonlab.cshl.edu/fastx_toolkit/libgtextutils-0.6.1.tar.bz2 Please let me know if it solves the complication issue, then I'll make it publicly available on the website. -gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626761: fastx-toolkit: fgets called with bigger size than length of destination buffer
Charles, I've put a fixed version here: http://hannonlab.cshl.edu/fastx_toolkit/fastx_toolkit-0.0.13.1.tar.bz2 Please let me know if it solves the complication issue, then I'll make it publicly available on the website. -gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625365: [d...@debian.org: [Debian-med-packaging] Bug#625365: libgtextutils: ftbfs with gcc-4.6 -Werror]
Hi Charles, I'm trying to fix it issue, perhaps you can help me with a strange compilation problem: I've installed a fresh VM of debian/testing and upgraded to unstable. I've installed g++ 4.6 ( gcc version 4.6.1 20110428 (prerelease) (Debian 4.6.0-6 ) ). When I run the configure of libgtexutils, I get: === $ export CC=gcc-4.6 $ export CPP=g++-4.6 $ ./configure ... ... ... checking command to parse /usr/bin/nm -B output from gcc-4.6 object... ok checking how to run the C preprocessor... g++-4.6 configure: error: in `/home/gordon/sources/libgtextutils-0.6': configure: error: C preprocessor g++-4.6 fails sanity check See `config.log' for more details === What am I doing wrong ? Is this a problem in the configure script (and requires reconf etc.) ? or something else ? Thanks, -gordon Charles Plessy wrote, On 05/03/2011 09:51 AM: forwarded 625365 gor...@cshl.edu thanks Dear Gordon, Debian is switching to GCC 4.6.x and FASTX-toolkit will need to be updated. See below for explanations. Cheers, -- Charles - Forwarded message from Matthias Klose d...@debian.org - Date: Tue, 03 May 2011 10:33:25 + From: Matthias Klose d...@debian.org To: mainto...@bugs.debian.org Subject: [Debian-med-packaging] Bug#625365: libgtextutils: ftbfs with gcc-4.6 -Werror Message-Id: e1qhcuz-0004et...@ravel.debian.org Reply-To: Matthias Klose d...@debian.org, 625365-mainto...@bugs.debian.org Package: libgtextutils Version: 0.6-1 Severity: important Tags: wheezy sid User: debian-...@lists.debian.org Usertags: ftbfs-gcc-4.6 ftbfs-werror This package builds with -Werror, and GCC 4.6 triggers new warnings which will make the package fail to build. Currently a Debian patch just passes -Wno-error=unused-but-set-variable and -Wno-error=unused-but-set-parameter to avoid build failures, but this patch will be reverted with the GCC 4.6.1 release, and the severity of the report will be raised. The full build log can be found at: http://people.debian.org/~doko/tmp/werror/libgtextutils_0.6-1_lsid64.buildlog The last lines of the build log are at the end of this report. ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging - End forwarded message - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625365: libgtextutils with GCC 4.6
Sorry about the previous email (the g++ fails sanity check) - it was my bad. Should have used CXX instead of CPP shell variables. I'm now able to compile libgtextutils using gcc/g++ version 4.6, and I'm not seeing the error you are mentioning. What should I change in order to reproduce the problem ? The commands I'm running: $ export CC=gcc-4.6 $ export CXX=g++-4.6 $ export CPP=cpp-4.6 $ wget -q http://hannonlab.cshl.edu/fastx_toolkit/libgtextutils-0.6.tar.bz2 $ tar -xjf libgtextutils-0.6.tar.bz2 $ cd libgtextutils-0.6 $ ./configure [... normal configure output ...] $ make And make completes successfully. I'm using: $ gcc-4.6 -v Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-6' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 20110428 (prerelease) (Debian 4.6.0-6) $ g++-4.6 -v Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-6' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 20110428 (prerelease) (Debian 4.6.0-6) Thanks, -gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
