bug#6906: [PATCH] cp: copy entirely-sparse files oodles faster

(triaging old bugs) Hello, On 17/04/11 10:28 AM, Paul Eggert wrote: On 04/17/11 01:55, Jim Meyering wrote: Now that we have FIEMAP support, (by the looks of things we will soon have SEEK_HOLE support in cp and in the linux kernel) do you think adding support for this special case is

bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

close 15926 stop (triaging old bugs) The original topic of using remove(2) call in rm(1) was decided to be undesirable. Starting at around the 33rd message [1] the thread diverges into bugs in "rm -rf ." and similar problems (which are resolved by the 221st message [2]. [1]

bug#19681: (no subject)

close 19681 stop Pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8b2bf5295f353016d4f5e6a2317d55b6a8e7fd00 closing.

bug#19375: (no subject)

tags 19375 fixed close 19375 stop pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=178f8e79dcd1e0b8bbb3b04da664d05eaae56186 closing.

bug#19154: (no subject)

tags 19154 fixed close 19154 stop Pushed in https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=16e2347bd545057b04a97115563e606ad822ec33 closing.

bug#12964: [PATCH] printenv: -n option added -- show names of variables.

(Triaging old bugs) Hello, On 22/11/12 03:42 PM, Van de Bugger wrote: Subject: [PATCH] printenv: -n option added -- show names of variables. * src/printenv.c: -n option added -- show names of variables. --- src/printenv.c | 17 + 1 file changed, 13 insertions(+), 4

bug#11540: [PATCH] tee: add a flag to ignore SIGPIPE

tags 11540 fixed close 11540 stop (Triaging old bugs) Hello, On 23/05/12 07:25 AM, Igor Ippolitov wrote: The default would be to diagnose write errors, and that could be changed with: --write-error={[cont],ignore,exit} In coreutils version 8.24 (released 2015) 'tee' gained the

bug#10013: man ls

tags 10013 wontfix close 10013 stop (Triaging old bugs) Hello, With no further comments in 6 years, the last consensus seems to be this addition is undesired. I'm marking this as 'wontfix' and closing. Discussion can continue by replying to this thread. regards, - assaf

bug#9430: [PATCH] Add new option --in-place

tags 9430 wontfix close 9430 stop (Triaging old bugs) Hello, On 03/09/11 10:50 AM, Jim Meyering wrote: Jim Meyering wrote: Picking up on an 18-month-old thread, Egan McComb found the tool I'd seen: sponge: Egan McComb wrote: > > The program that works similarly is called sponge,

bug#7257: [PATCH] Correct typos in date

tags 7257 fixed close 7257 stop (Triaging old bugs) Hello, On 17/04/11 03:04 AM, Jim Meyering wrote: Tobias Quathamer wrote: I think I've found three typos in the date program. I've attached a patch correcting those. There was some discussion at http://debbugs.gnu.org/7257 and one change

bug#7176: [PATCH] human: add unambiguous block_size_args

tags 7176 wontfix close 7176 stop (Triaging old bugs) Hello, On 16/04/13 11:12 AM, Mihai Capotă wrote: On Sun, Apr 14, 2013 at 1:52 AM, Pádraig Brady wrote: So I was 50:50 on making this change, and in the meantime numfmt(1) was released, which gives full control over number formatting,

bug#6366: comm: use numeric sort (optionally)

severity 6366 wishlist stop (triaging old bugs) Hello, On 22/08/12 04:00 PM, Pádraig Brady wrote: On 08/22/2012 09:17 PM, Sam Steingold wrote: I have a file of numbers (integers IDs) which are sorted numerically, but comm complains that they are not. I suggest that comm accept "-n" option

bug#6056: base32 output for md5sum sha1sum etc.

(triaging old bugs) Hello, A new "base32" program was added coreutils version 8.25 (released 2016). Now it is easy to run something like: sha1sum ... | cut -f1 -d' ' | xxd -r -p | base32 As such (after 8 and a half years), I'm marking this as "closed". Discussion can continue by replying

bug#32807: file system type 0x794c7630

Hello, On 22/09/18 10:41 AM, Thorbjörn 'Puggan' Sundragon wrote: "tail: unrecognized file system type 0x794c7630 for 'ekonomic-access_log'. please report this to bug-coreutils@gnu.org. reverting to polling" Thank you for the report. This has been fixed in version 8.25 and later. for more

bug#32762: Bug at coreutils compile

tag -1 notabug close -1 thanks Hello, On 18/09/18 02:49 AM, vvcfee wrote: Hi GNU team,Thanks for your great job! Thank you for the kind words. recently I try to compile gnu coreutils manually on Centos7.3,and got some error when try to make: [root@localhost coreutils]# make make

bug#32577: Bug with Docker image run

Hello, On 29/08/18 10:45 AM, Pierre wrote: tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’. please report this to bug-coreutils@gnu.org. reverting to polling Thank you for the report. This has been fixed in later versions (since version 8.25, released in January 2016).

bug#32533: my documentation improvement proposals are in most cases not answered

Hello, On 25/08/18 12:46 PM, kalle wrote: I mostly read info- and man-documentation of elementary GNU-programs and here and then send a bug-report on this documentation, if I consider it bad or improvable. Thank you for sending those - we do appreciate and suggestions and contributions,

bug#32380: Reporting error

Hello, On 06/08/18 04:11 PM, Chian Teng Ong wrote: Reporting as per instructed. See attachment. for reference, the error is: [] tail: unrecognized file system type 0x794C7630 [] from inside a docker container. Thanks for reporting this. Support for this file system

bug#32099: Benchmarks: Hashing ~70% faster (Was: New uniq option for speed)

tag 32099 notabug severity 32099 wishlist close 32099 stop Hello Kingsley, On 09/07/18 10:29 PM, Kingsley G. Morse Jr. wrote: And I like your benchmarks. Mine are humbly attached. They compare sorting to hashing. At the moment, hashing seems to me to be about 70% faster. And to scale

bug#32099: New uniq option for speed

Ηello, On 08/07/18 03:03 PM, Kingsley G. Morse Jr. wrote: The main reason I'm writing is to humbly suggest a performance improvement to the "uniq" command. It currently requires its input to be sorted. Sorting generally takes about O(N*log(N)) time. However, it seems to me that sorting is

bug#31882:

Hello, On 17/06/18 11:43 PM, frogg616 wrote: tail: unrecognized file system type 0x794c7630 for '/var/log/apache2/access.log'. please report this to bug-coreutils@gnu.org. reverting to polling Thank for the report - this file system has been added in coreutils 8.25. For more details see

bug#30989: Bug in "tail"

Hello, On Thu, Mar 29, 2018 at 05:09:15PM +0200, Florian Lutz wrote: > > tail (GNU coreutils) 8.23 > [...] > unrecognized file system type 0x794c7630 for ‘current’. please report > this to bug-coreutils@gnu.org. reverting to polling > > Thus i am writing this e-mail. It was used on an

bug#30987: bug!

Hello, On Thu, Mar 29, 2018 at 01:04:38PM +0100, Angel wrote: > tail: unrecognized file system type 0x794c7630 for 'error.log'. please > report this to bug-coreutils@gnu.org. reverting to polling Support for this filesystem has been added in recent versions of coreutils. for details see here:

bug#30795: Issue with date command and EDT

Hello, On Wed, Mar 14, 2018 at 05:22:04PM -0700, Paul Eggert wrote: > On 03/13/2018 06:42 PM, Assaf Gordon wrote: > >Therefore it is always recommended to use noon (12pm) > >as explicit time when adjusting days > > Maybe "date" should default to 12:00 in

bug#30795: Issue with date command and EDT

Hello, On 2018-03-13 09:20 AM, Jared Chagnon wrote: I setup a test script: #/bin/bash echo "`date`" echo "`date +%z`" currentdate=`date +%Y%m%d_%H%M%S` echo "current date: $currentdate" olddate=`date "+%Y%m%d_%H%M%S" --date='4 days ago'` echo "old date 4 days ago: $olddate” An unrelated

bug#30718: coreutils-8.29 compilation failure using xlC on AIX

On 2018-03-05 06:21 PM, Paul Eggert wrote: On 03/05/2018 04:01 PM, John Wiersba wrote: As an additional comment, it took me quite a while to find working values for CFLAGS, AR, and LDFLAGS.  I'm not sure how you might accomplish it, but it would be friendlier if, once it's determined that gcc

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

Hello Ian, On Thu, Feb 15, 2018 at 07:44:39PM -0500, Ian Morris Nieves wrote: > Attached please find a new feature I created to simplify setting permissions > (especially recursively), which enables the user to separately target files > or directories. Can you provide a concrete

bug#26101: Counterproductive calculation order in date

ed date part: (Y-M-D) 2016-02-29 date: parsed relative part: +1 year(s) [...] date: warning: month/year adjustment resulted in shifted dates: date: adjusted Y M D: 2017 02 29 date:normalized Y M D: 2017 03 01 [...] By using the 15th of the month, adding years becomes more intu

bug#30313: tail: unrecognized file system type

tag 30313 notabug close 30313 stop Hello, On 2018-01-31 02:31 PM, kklepper wrote: tail: unrecognized file system type 0x794c7630 for Thank you for the report. Support for this file system has been added in version 8.25. You are likely using an older version. For more information, please

bug#30102: date -d 'next tuesday, 2 years ago' # Is something like that supported?

tag 30102 notabug close 30102 stop Hello, On 2018-01-13 05:03 PM, bug-coreut...@trodman.com wrote: $ date --version date (GNU coreutils) 8.27 In version 8.27 the date command has an additional option called "--debug" which can help in understanding the date parsing. I will use it in the

bug#29809: a bug with the "tail" command

Hello, On 2017-12-21 09:49 PM, Jan Rogoyski wrote: tail: unrecognized file system type 0x53464846 for 'list'. please report this to bug-coreutils@gnu.org. reverting to polling Thank you for the report. This file system (wslfs - windows subsystem for linux) has been added to coreutils 8.26

bug#29606: Command 'fold' dangerous with utf-8 input

Hello Mark, First, thank you for taking the time and effort to test our development snapshot, and reporting results back. This kind of feedback is critical in getting multibyte support ready. Second, I can confirm the behavior you are observing, reproduced here with 'od' for easier output: ##

bug#29606: Command 'fold' dangerous with utf-8 input

Hello, On 2017-12-07 03:10 AM, Mark Roberts wrote: I am using fold version 8.13 on a Debian 3.2.93-1 Do you mean Debian 7 (Wheezy) with Linux Kernel 3.2.93-1 ? cat filename | fold If 'filename' contains utf8 characters consisting of more than one byte, fold will consider breaking the

bug#29421: bug in command "tr"

tag 29421 notabug close 29421 stop Hello, On Thu, Nov 23, 2017 at 6:01 PM, wangjian wrote: > Hi there, I think this is a bug > > mkdir empty_foler > cd empty_foler > touch a > echo "abc" | tr [:blank:] + # you will get “+bc” as output, instead of “abc” > touch b > echo

bug#29396: Comm bug verified

(re-adding the mailing list) Hello, On 2017-11-22 12:39 PM, Saint Michael wrote: Thanks for the explanation Is there a place to download the source code? I want to compile a version that ignore spaces on the right, since 99% of the time I forget to check the line endings. or maybe you could

bug#29396: Comm bug verified

tag 29396 notabug close 29396 thanks (based on reproducible example provided privately) Hello, On 2017-11-22 09:48 AM, Assaf Gordon wrote: On 2017-11-22 07:15 AM, Saint Michael wrote: I have two files with phone numbers, one column, sorted (they pass the test sort -c). One is large

bug#29396: Comm bug verified

Hello, On 2017-11-22 07:15 AM, Saint Michael wrote: I have two files with phone numbers, one column, sorted (they pass the test sort -c). One is large and the other one is small. The comm -12 --check-order file1.csv file2.csv falis to find matches, but another utility, join file1.csv

bug#28763: docbug (stat -t): missing field names in docs(manpage) for 'stat -t'

On 2017-10-30 04:28 AM, Bernhard Voelker wrote: On 10/12/2017 08:51 AM, Assaf Gordon wrote: Attached an updated patch. +1 Thanks & have a nice day, Berny Thank you, pushed here: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5ab71e4d3 I'm thus closing this bug. reg

bug#29069: info coreutils file permissions: improvements/bug-report

tag 29069 notabug stop Hello, On 2017-10-30 02:38 PM, kalle wrote: here some improvement proposals/bug report on info coreutils file permissions: -in my opinion it would be good to explain the general idea bihind the file permissions a bit more. what the issues are etc. Elese one doesn't

bug#29062: PRINTF

tag 29062 notabug close 29062 stop Hello, On 2017-10-29 04:59 AM, archit soni wrote: my name Archit soni.i studying in B.E in I.T. MY friend name is Parth prajapati .he is studying in B.Tech.he has some may bug in printf in c.We are some situation face in printf.I have already attached image

bug#29044: sort --debug results improvement

tag 29044 notabug close 29044 thanks Hello, There are few issues at hand. Answering out of order: > $ sort -k 2n -k 3n --debug file.txt [...] > Also the user is confused if > > is a "key 3", or just a separator. > > Therefore please say > ": key 1" or "1" etc. at the end of

bug#28763: docbug (stat -t): missing field names in docs(manpage) for 'stat -t'

- assaf >From 00c5dd601c8227e1384de314e8a5dc420a56b272 Mon Sep 17 00:00:00 2001 From: Assaf Gordon <assafgor...@gmail.com> Date: Wed, 11 Oct 2017 22:33:28 +0200 Subject: [PATCH] stat: output default formats for --terse in usage Suggested by L A Walsh in https://bugs.gnu.org/28763 . * src/stat.c (fmt_terse_fs): D

bug#28763: docbug (stat -t): missing field names in docs(manpage) for 'stat -t'

On 2017-10-11 02:39 PM, Bernhard Voelker wrote: > On 10/11/2017 09:26 PM, Assaf Gordon wrote: >> What do you think ? > > Nice but redundant. > WDYT about something like the attached? Indeed, much better. Thanks! -assaf

bug#28763: docbug (stat -t): missing field names in docs(manpage) for 'stat -t'

, one adds the information at the end of the "--help" screen, the other inside the "--terse" parameter. (these will also be propagated to the man-pages). What do you think ? regards, - assaf >From c3a1564093dab6b2660969edb06f65f7c9655e80 Mon Sep 17 00:00:00 2001 From: Assa

bug#28763: docbug (stat -t): missing field names in docs(manpage) for 'stat -t'

Hello, On 2017-10-09 12:59 PM, L A Walsh wrote: > I typed stat -t to look at the terse form of 'stat', and see > a bunch of numbers -- but nowhere do I see what those numbers > are suppose to be (i.e. they aren't documented in the manpage > and they obviously aren't the same as what is in the

bug#28657: Random sort-order in du

tag 28657 notabug stop Hello, On 2017-09-30 03:41 PM, Holger Klene wrote: > * Assaf Gordon <assafgor...@gmail.com> [30.09.17 15:08]: >> But if you use shell-globbing, the shell will automatically >> order the directory alphabetically: > >> $ du -c -hd1 data/* &

bug#28657: Random sort-order in du

Hello, On 2017-09-30 02:45 PM, Holger Klene wrote: > > du -hd1 /media//backintime///1/ [...] > Now du returns something like: > 1G2016 > 0G2015 > 0G 2017 > 1G . > > [...] > > But now the order determines, which folder the size is reported against. But > I had to learn, that > the

bug#28528: Split command problems.

Hello, On 2017-09-29 04:11 AM, Nick Farrow wrote: > still with the same hash differences.  > > split -b 3276800 -d largefile largefile. I'm unable to reproduce this issue. I've tried the above command on two different machines, one of which is an RPi3 similar to yours (armv7l with split version

bug#28582: Coreutils 'make check' failure due to expr change

On 2017-09-24 01:36 PM, Pádraig Brady wrote: > > You weren't on latest git? > It was addressed 4 days ago with: > https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3a3f5f3 heh, I missed it as well. Thanks for fixing it! -assaf

bug#28528: Split command problems.

Hello, On 2017-09-20 01:04 AM, Nick Farrow wrote: > When I use the coreutils split command on a file. I get the parts with no > problem. But when trying the same exact command on the same exact file on a > different server the hashes checks of the parts vs the other server don’t > match. Is there

bug#28461: erreurs

On 2017-09-17 06:47 PM, Jim Meyering wrote: > On Sat, Sep 16, 2017 at 11:27 PM, Assaf Gordon <assafgor...@gmail.com> wrote: > ... >> Attached an updated patch with all instances of 'parameter' >> changed to 'argument'. > > Looks fine. Thank you! > I marked th

bug#28461: erreurs

all instances of 'parameter' changed to 'argument'. regards, - assaf >From af73836848da7e391bcfc06008a34db5aa9ad304 Mon Sep 17 00:00:00 2001 From: Assaf Gordon <assafgor...@gmail.com> Date: Fri, 15 Sep 2017 00:36:13 -0600 Subject: [PATCH] expr: add detailed syntax error messages Show o

bug#28468: Bug in wc -l found

tag 28468 notabug stop Hello Rob, On 2017-09-15 03:03 AM, Weidner, Robert (I/EE-31, extern) wrote: > seems I found a bug in wc, have a look: [[ the attach screen shot shows: $ wc -l monitore-serNr_all-run2.txt 16 while the attached file appears to have 17 lines. ]] This is not a bug,

bug#28461: erreurs

Perhaps something like the attached? (not fully tested...) -assaf >From 4bb5771832a397e2db3704feaf0ece52cdd65a55 Mon Sep 17 00:00:00 2001 From: Assaf Gordon <assafgor...@gmail.com> Date: Fri, 15 Sep 2017 00:36:13 -0600 Subject: [PATCH] expr: add detailed syntax error messages Show offending

bug#28461: erreurs

tag 28461 notabug stop Hello, On 2017-09-14 11:43 AM, Eric Mariaud wrote: > eric@Eric-Xub:~/Bureau$ expr 2 + 3 > 5 > eric@Eric-Xub:~/Bureau$ expr 2 * 3 > expr: erreur de syntaxe The asterisks ( * ) character has special meaning on the shell, which you can observe by comparing the output of:

bug#28228: split issue?

tag 28228 notabug close 28228 thanks Hello, On 24/08/17 02:02 PM, Xikai Jiang wrote: > When I use 'split -d -l 3 my.file' to split a file, there seems to be a > discontinuity in the numeric suffixes of the resulting files (x89 to x9000, > see the attached image.) > > Could you help on this

bug#28038: expand(1) lacks MBC support

Hello Tilman, On 10/08/17 10:10 AM, Tilman Schmidt wrote: > it seems the expand(1) command does not properly support multi-byte > characters. That is correct. > tschmidt@sl-vm-redmine01:~$ cat test.txt > Text ohneUmlaute > Täxt müt Umläuten > tschmidt@sl-vm-redmine01:~$ expand

bug#28014: Join Documentation Error

tag 28014 fixed close 28014 stop Hello, On 08/08/17 05:31 AM, Phlosioneer wrote: > Looking at the official coreutils documentation for join: at > > https://www.gnu.org/software/coreutils/manual/html_node/join-invocation.html > > The result of the example is incorrect. Fix pushed here:

bug#28014: Join Documentation Error

file2 > a 1 X > e 5 Y Thank you for the report. The attached patch should fix it. I'll push it soon if there are no objections. regards, - assaf >From 40988dd16111f72413d18d8bff296087bcfa3b8c Mon Sep 17 00:00:00 2001 From: Assaf Gordon <assafgor...@gmail.com> Date: Tue, 8 Aug 2017

bug#26779: expr length

> On Jun 28, 2017, at 12:32, Pádraig Brady <p...@draigbrady.com> wrote: > > On 27/06/17 18:41, Assaf Gordon wrote: >> Attached work-in-progress for expr/multibyte, > This looks to have sufficient testing and is ready to push. > We can look at using wide strings in

bug#26779: expr length

Hi, Attached work-in-progress for expr/multibyte, hopefully fixing all (most?) of the coding style issues (Internal conversion to wide strings not yet implemented). Comments welcomed, - assaf 0001-expr-add-multibyte-support.patch.gz Description: application/gzip

bug#27358: Timeout command was get failed to kill soffice.bin processes

Hello Ken, On Wed, Jun 14, 2017 at 03:58:19PM +0530, Ken Walker wrote: [...] unoconv command start soffice.bin proccess for convert file and it working fine to kill that unoconv + soffice.bin process by timeout command if taken more than time which define with timeout command, But sometime it

bug#26779: expr length

Hello, Attached an updated version of the 'expr/multibyte' patch. > On May 9, 2017, at 08:31, Pádraig Brady wrote: > Definitely needs a NEWS entry > and mention of this bug in the commit message. I added two NEWS entries: one for the bug fix and one for the new multibyte

bug#26779: expr length

> On May 9, 2017, at 03:04, Assaf Gordon <assafgor...@gmail.com> wrote: > > Attached a draft patch implementing multibyte support for 'expr' > (it doesn't need any code from my previous multibyte stuff, so I'm sending it > separately). > [...] > > <0001-expr-ad

bug#26779: expr length

Hello, > On May 4, 2017, at 11:43, Pádraig Brady wrote: > > On 04/05/17 02:59, Андрей Воронов wrote: >> I have the bug in expr utility when it perform operation of the >> calculating length of the string in my multi-byte encoding ru_RU.UTF-8. > > expr is listed in the

bug#26372: Base64 inserts newline [was "Base64 inserts carriage return"]

Hello, On 04/05/2017 07:35 AM, Goulven Guillard wrote: > I just figured it was not a carriage return ("\r") but a simple newline > ("\n"). I was misleaded because for some reason my PHP form translates > "\n" into "\r\n" during the POST submission. While PHP and HTTP are outside the scope of

bug#26372: Base64 inserts carriage return

tag 26372 notabug close 26372 stop Hello, On 04/05/2017 06:39 AM, Goulven Guillard wrote: > It seems `base64` inserts a carriage return ("Cg==") when encoding a > string : > > $ echo foobar|base64 > Zm9vYmFyCg== Not exactly - it is "echo" which adds the newline and base64 simply encodes all

bug#26362: tr -cd -- Problem with UTF-8?

tags 26362 notabug wishlist stop 26362 Hello, > On Apr 4, 2017, at 10:01, Ronald Schaten wrote: > > I'm not sure if this is bug or if I'm using it wrong. Neither - it is simply the GNU tr does not yet support multibyte characters. > The simplest way to reproduce this

bug#26029: Problems with join

it in the 'gotcha' page. Comments welcomed, - assaf >From d0d51f85cc6f1ce1a330bd45b4072778b74b0cc9 Mon Sep 17 00:00:00 2001 From: Assaf Gordon <assafgor...@gmail.com> Date: Thu, 30 Mar 2017 22:58:46 -0400 Subject: [PATCH] doc: mention obsolete join -j1/-j2 syntax '-j1 N' is equivalent

bug#26293: GNU date program

tags 26293 notabug close 26293 stop Hello, > On Mar 28, 2017, at 22:26, Dean Gibson AE7Q wrote: > > Consider: "date -d '2017-03-28 17:12:34 + 3 hours'" Due to the way date strings are parsed, the "+3" part is used as the input time zone (+03:00) and then the "hours"

bug#26101: Counterproductive calculation order in date

Correcting my own mistake: > On Mar 15, 2017, at 10:40, Assaf Gordon <assafgor...@gmail.com> wrote: > > When adjusting days, it is equivalent to subtracting > the number of seconds from the current unix epoch (i.e. seconds since > 1970-01-01). > [...] Adjusting days is

bug#26101: Counterproductive calculation order in date

Hello, > On Mar 15, 2017, at 11:53, Pádraig Brady wrote: > > Yes that's an awkward gotcha (I'm not sure is related to the OP's issue). > I outlined a solution at http://bugs.gnu.org/18159#8 > I didn't document in "coreutils gotchas" as it's covered in "coreutils FAQ", >

bug#26101: Counterproductive calculation order in date

> On Mar 15, 2017, at 09:43, Ulf Zibis wrote: > > Am 15.03.2017 um 13:44 schrieb Eric Blake: >> Maybe you are confused on how date implements "subtract a month". It >> does NOT do "subtract 28, 29, 30, or 31 days as appropriate", but rather >> does "subtract 30 days, for lack

bug#26029: Problems with join

Hello Reuti and all, Reuti wrote: […] The strange thing seems to be, that "-j1 2" is handled like "-1 2". My investigations revealed: on a Mac the man page of `join` explains the behavior. The options -j, -j1 and -j2 are listed with the BSD version of `join` as being there for compatibility.

bug#25870: give an example to show what lines join -a and -v are talking about

> On Feb 27, 2017, at 16:02, Assaf Gordon <assafgor...@gmail.com> wrote: > [...] > > I've added all combinations to the 'unpaired lines' section, > and also added the examples from your website to a new section "Set > operations on files". > > Comm

bug#25870: give an example to show what lines join -a and -v are talking about

Hello, Thank you for your good comments. > On Feb 27, 2017, at 05:26, 積丹尼 Dan Jacobson wrote: > > but it seems at the beginning there still lacks the > most basic "Hi kids, here is the 'join' command [...] before you get into any > more niceties. I like this approach.

bug#25870: give an example to show what lines join -a and -v are talking about

Hello Dan, > On Feb 25, 2017, at 08:20, 積丹尼 Dan Jacobson wrote: > [...] > And in fact give an example to show what lines -a and -v are talking about! > Good idea. Here's a rough draft. comments welcomed, - assaf 0001-doc-expand-join-section.patch.xz Description: Binary

bug#25832: split (v 8.25) with numeric suffixes beyond 89

> On Feb 21, 2017, at 22:32, Pádraig Brady wrote: > > This was discussed at http://bugs.gnu.org/20874 Missed that - sorry. I should've looked through the archives first... > I'm not sure anything needs to be done here, > since for backward compat for concat operations >

bug#24924: pr has no concept of wide characters

severity 24924 wishlist tags 24924 wishlist notabug thanks Hello Dan, On 11/11/2016 11:10 AM, 積丹尼 Dan Jacobson wrote: The pr documentation (man, info) doesn't mention how it has no concept of wide characters. $ pr -m --sep-string='^^^' file file Indeed, most of the current coreutils

bug#24906: gnu sort, what am I doing wrong?

Hello Arnold, > On Nov 8, 2016, at 23:23, Arnold Robbins wrote: > > $ grep -v ^# checkbook.txt | sort -t: -k5 -k6rg > [...] > Why aren't these sorted by amounts in descending order? > What am I missing? The option "-k5" means "field 5 till the end of the line", which

bug#24800: expr 8.25 seems to treat 0 in character class in paren incorrectly

Hello, On 10/26/2016 12:15 PM, Paul Eggert wrote: There's no bug here: "expr E" exits with status 1 if E evaluates to 0, and expressions like "0 : '\([0-9]\)$'" do evaluate to 0. Worth mentioning that this is a known "gotcha", explained here:

bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other

Hello, > On Oct 18, 2016, at 17:35, Linda Walsh <coreut...@tlinx.org> wrote: > > Assaf Gordon wrote: >>> rmdir -p ./a/b/c # get error msg, but a,b,c removed. > I see... so in ".a/b/c", a,b,c are removed, but the error > comes in "."? Yes

bug#24730: rmdir/mkdir error(s) and/or not working "reciprocally" w/each other

Hello, Before deciding on the wording, it's worth nothing that the errors and reasons for the errors are different between mkdir and rmdir, and between the two cases. On 10/18/2016 03:49 PM, L. A. Walsh wrote: mkdir -p ./a/b/c # no error rmdir -p ./a/b/c # get error msg, but a,b,c

bug#24601: Update

Hello, Attached is my test program for strcoll. It is slightly big, but mostly because of additional help and debug printing. This will also become relevant when we deal with multibyte sort/join/uniq later on. From brief testing, it seems glibc with UTF-8 locales is the only libc that has

bug#24601: Update

Hello, On 10/04/2016 11:27 AM, Paul Eggert wrote: On 10/04/2016 07:12 AM, mathew wrote: I reported the issue to the glibc maintainers, but they seem skeptical. They don't sound that skeptical to me. They just want a test case that

bug#24599: Cannot process files named -

tag 24599 notabug close 24599 stop Hello, On 10/03/2016 02:12 PM, João Miguel wrote: I initially thought this was not a bug (found no report about this in these mailing lists while searching for «file named ""-""»), but it works as expected with vi ("vi -" tries to read stdin, "vi -- -" edits

bug#24349: Linux info date example

Hello, On 09/01/2016 08:40 AM, Sergiu Druta wrote: ~$ date -d 1may '+%B %-d In above example there is a single mark quotation ( ' ) missing at the end of example. Thank you for the report. The attached patch (in your name) adds the quote. If you approve, and there are no other comments,

bug#24054: tr bug? [:space:] acts like "a"

tag 24054 notabug close 24045 stop Hello, On 07/22/2016 02:58 PM, p...@tutanota.de wrote: For the last few weeks tr [:space:] isn't working the way it used to for me under Ubuntu 14.04. Instead of acting on spaces it acts on "a"s.: me@U:~$ echo "thisstring abcde what the heck?" | tr

bug#24011: parallel find error

tag 24011 notabug close 24011 stop Hello, > On Jul 16, 2016, at 15:42, jklowden wrote: > > There appears to be an error in the parallel execution of find. I > created a minimal example below. > > [...] > > $ find .. -type f -name lx[tr]\*.1 -exec basename {} + >

bug#24011: parallel find error

tag 24011 notabug close 24011 stop Hello, > On Jul 16, 2016, at 15:42, jklowden wrote: > > There appears to be an error in the parallel execution of find. I > created a minimal example below. > > [...] > > $ find .. -type f -name lx[tr]\*.1 -exec basename {} + >

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

tag 23951 notabug close 23951 stop Hello, quoting an off-list email from David: > When I use "sort -k1.4n -u", system output miss [c3m1.ecld.com]. > then "sort -k1.4n aa |sort -u" the [c3m1.ecld.com] appear again. This is not a bug but correct behavior. The parameter "-k1.4n" means that the

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

Hello, > On Jul 11, 2016, at 21:38, David Pan wrote: > > It seems that I find a bug when using the command: > > sort -k1.4n -u > please refer to the attachment for detail . You have not indicated exactly what is the suspected incorrect output. May I ask you to detail what

bug#23922: cut fails for non-delimited input lines with -f 2

tag 23922 notabug close 23922 stop Hello Jens, > On Jul 8, 2016, at 19:05, Jens Mueller wrote: > > $ echo "abc" | cut -f 2 -d " " > > and I expect the empty line as output but you get "abc\n". It is not a bug, but correct behavior (though perhaps unexpected) to print

bug#23673: wrong sorting order

tag 23673 notabug close 23673 stop Hello Alain, On 06/01/2016 09:16 AM, alainm wrote: I need to perform a sort based on the first 3 indexes of a line (sort -k 1,3 -n truc.lst): The 0 coordinates are not placed before the 2 coordinates, it looks like the spaces are ignore: [...]

bug#23665: spaces in keys: doc, --debug in LC_ALL=C

Hello Karl and all, > On May 31, 2016, at 19:15, Karl Berry wrote: [...] > I'm not sure what you mean by [...]. The %lu? > Are you proposing to just add the word "sort"? That's not needed IMHO. I was suggesting exactly that :) Also, the word "key" appears in few other

bug#23665: spaces in keys: doc, --debug in LC_ALL=C

Hello Karl! On 05/31/2016 02:32 PM, Karl Berry wrote: I run LC_ALL=en_US.UTF-8 sort --debug -k 2 /tmp/foo # or -k 2,2 et al. And get the nicely explanatory output for the "surprising" result: [...] Just to verify, the surprising result is in C locale? I'm seeing the following, for

bug#23556: sort(1): misleading description of option -n

Hello Carsten, On 05/14/2016 10:17 AM, Carsten Hey wrote: the man page sort(1) contains a misleading description of the option -n: [...] $ man sort | grep -A1 -- --numeric-sort | sed -n -e 's/^ *//' -e '1!p' compare according to string numerical value [...] This description reads

bug#23448: stdbuf exit code does not reflect child status

tag 23448 notabug thanks Closed based on off-list response from submitter. -assaf

bug#23448: stdbuf exit code does not reflect child status

Hello, On 05/04/2016 10:48 AM, Larry Wilson wrote: How can I get the exit status of the command I am running? I'm not able to reproduce this error. Notice the following: $ stdbuf -oL false && echo ok || echo fail fail $ stdbuf -oL true && echo ok || echo fail ok $ stdbuf -oL sh

bug#23268: sort ant uniq bug report

(adding debbugs mailing list) Hello, On 04/11/2016 12:43 PM, 126 wrote: Thank you for your reply. I'm sorry for not describe my problem clearly. Every other input is working well,but when my input contain several lines of "src/table/checkpoint/checkPointInfo5000.lua". The result of (sort -u)

<    1   2   3   4   5   6   >