Re: [PATCH] Add new program: magic

[EMAIL PROTECTED] wrote: | So far, it includes the following utilities: | - sponge: soak up standard input and write to a file Eh? That sounds like 'cat > file'... -- Matthew Look! A randomly selected yet highly appropriate signature! ___ Bug-cor

Re: avoid mkdir/selinux failure when mknod is a shell built-in

Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/16/2008 6:30 AM: | My first reaction was "great! that looks much better". | Unfortunately, the technique doesn't work with that shell: | | openbsd$ ./mknod --version|head -1 | mknod (GNU coreutils)

Re: RM disregards file level permissions and uses directory permissions instead.

Eric Blake wrote: In particular, the EACCES errors on unlink() mention that without the sticky bit, all you need is write access to the directory (and your directory is world writable); with the sticky bit set, you must also own the directory and file. ^^^ To stave off confusion.

Re: Feat-Req: uniq -c delimiter should be changable

Maximilian Haeussler wrote: Let's say I only want the 50 most common lines of a file: cat textfile | sort | uniq -c | sort -n | tail -n 50 | tr -s ' ' | cut -f2 Have I ever mentioned that 'sort | uniq -c' really ought to be folded into sort proper? (Not to get rid of 'uniq', but 'sort | uniq -

Re: is hard-coding the group name, "tty", portable enough for who -a?

Jim Meyering wrote: If anyone can find a system on which this prints something other than "tty", please let us know: stat --format %G $(tty) I get my primary GID on AIX 4.3 and Irix 6.5, and "terminal" on OSF1 5.1. The OSS I have access to probably isn't a "reasonable porting target" :-),

Re: md5sum results with V5.2.1 and V5.97 differ

Aparna Rallabandi wrote: I have a dev box where there is version 5.2.1 of md5sum. The result of md5sum --string on a string say "654321" is different from that of "echo \"654321\" | md5sum --text". Of course it is. One of those ends with a '\n'. Also, the way you quoted above is confusing. It

Re: Feature Requests?

Robert Dvoracek wrote: Hello. Do you take feature requests here? Sure. -- Matthew "Who wants to sing?" -- Orcs (Warcraft II) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Feature Requests?

ROBERT DVORACEK wrote: Matthew Woehlke wrote: Robert Dvoracek wrote: Hello. Do you take feature requests here? Sure. Great. I sent one a while back but I'm not sure if anyone got it. It was a request for a sort of binary file option in csplit which uses bytes instead of lines

Re: Surprising bug in sort

Eric Blake wrote: According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM: Thank you very much for the clarification, it makes perfect sense to me now - as I said I was surprised that I appeared to have found a bug. I have now reread the documentation and I still don't think it is particularly cle

Re: bug in sort manpage: -k syntax is wrong

Jeff Lerman wrote: I note that in the manpage for the "sort" utility, the -k flag syntax claims that an "=" should be used between the flag and the argument(s). Quoting: -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) This is incorrect and results in a

Re: source code

Michael Williamson wrote: I do not have a bug to report. I have a question. Where is the source code for the program "tail". I cannot find a "tail.c" on Fedora or openSuSE. You want the SRPM for "coreutils". There is a tail.c in src/ (at least in 6.9, but I doubt it's been moved). You could

Re: Undocumented values of ls --color

Bjoern Voigt wrote: Hello, as I played a bit with the "--color" option of "ls" I found, that some values of "--color=WHEN" are undocumented. The valid options of "--color=WHEN" are according to the source code coreutils-7.0/src/ls.c:828: static char const *const color_args[] = {

Re: Aide sur Ubuntu

Aboubacar KADRI wrote: Bonjour J'ai un problème pour vider la corbeil. Quelle commande utiliser pour pouvoir la vider? Merci. This is an English-language list. Since I do not speak French, I have attached a copy of this message, translated with Google, below. Also... (I am going to quote Er

misdirected ubuntu requests (yes this is relevant)

(First, my apologies to Bob Proulx, who apparently (according to Eric anyway) penned the canned reply first, for the misattribution.) After the latest incident of misdirected Ubuntu requests (in French, no less), I decide to file a bug against Ubuntu [1]. Ondřej Vašík wrote: One confusing thi

Re: tail --recursive

Simon Windows wrote: I've attached a modified version of tail.c from coreutils-6.12.The changes are fairly small but will look a lot bigger in a diff as I've split tail_forever() into two functions so it can be called recursively. Your attachment seems to be missing? -- Matthew Please do not q

Re: tail --recursive

Simon Windows wrote: Jim Meyering wrote: I haven't looked at it at all yet, but wonder if you've considered using inotify? That seems like that mechanism would be much more appropriate, when tailing many files in an arbitrary hierarchy. I have looked at the inotify library as you suggested. I

Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them

Ondřej Vašík wrote: Andreas Schwab wrote: Eric Blake writes: Would a double --verbose make sense? +1 from the random user/lurker :-). --verbose=2 Rather than some level-numbers I do prefer --verbose and --verbose=high ... $0.02: I'm lazy, I like '-vv' :-). (Whichever way is fine for the

Re: Possible bug with grep/sed/tail?

Jim Meyering wrote: make >& log & line-buffer tail -F log --pid=$! | grep warning: Doesn't 'tee' line-buffer by default? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Is this thing on? ___ Bug-coreutils ma

Re: [bug #24949] coreutils pwd not implementing latest POSIX features

Paul D. Smith wrote: On the other hand, I think it would not actually be that difficult to implement -L. It seems to me that Eric Blake's description of what it would take to adhere to the POSIX standard, as he describes here: http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00258.html

Re: Support in sort for human-readable numbers

Vitali Lovich wrote: Additionally, you've got problems like mu for micro, which I'm not even sure can be represented in ASCII. I know I use "u" in this case. I'm not sure how wide-spread that is (or if it's even not a personal quirk, though I want to say I've seen it elsewhere). -- Matthew

Re: Support in sort for human-readable numbers

Vitali Lovich wrote: Perhaps - but for sort, at least from my thinking of how I would implement this, the additional logic (at least to behave correctly on all inputs) would be somewhat complicated. Can you please explain why you believe this belongs in sort and wouldn't be better served by pre-

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

Aaron Peterson wrote: Note, interactive, and no-clobber don't have to be exclusive... Here is an example of them combined: Interactively see if the person wants to overwrite, then say, oh, you can't do it because you told me not to. Then -n -i would say it can't overwrite a certain file, and no

Re: [md5sum]

Pedro Henrique Marques wrote: But the output shows the verification only from the 3� to last file: To clarify, the problem is that the first and last file were apparently ignored? My md5sum version is 5.2.1 Is this a bug ? The latest version of coreutils is 7.0. I recommend trying a newe

Re: ls -s documentation misleading

vcap...@pengaru.com wrote: The ls -s argument is documented as such: ls --help output: -s, --size print the size of each file, in blocks LS(1) man page: -s, --size print the size of each file, in blocks This leads one to expect some sort of relationsh

Re: feature requests: trunc and maybe cmddiff

Pádraig Brady wrote: Note there have been a few patches to add progress bars to cp/mv. For e.g..: http://lists.gnu.org/archive/html/bug-coreutils/2007-12/msg00212.html However you can use `rsync -aP my_file my_file.2` to copy locally with progress. FWIW, I most often would find a progress bar f

Re: feature requests: trunc and maybe cmddiff

Pádraig Brady wrote: Matthew Woehlke wrote: (* what happened to adding a coreutil to fix [block buffering vs. line buffering], did it ever happen?) Are you talking about stdbuf? That's on the way soon. That sounds familiar. Thanks for the info. -- Matthew Please do not quote my e

Re: ready for a bug-fix coreutils-7.2?

Jim Meyering wrote: I want to make a coreutils-7.2 release soon. There are still a few minor problems we haven't been able to reproduce (like the install-related test failure), and some portability problems, but there have been enough real bug fixes, http://git.sv.gnu.org/cgit/coreutils.git/p

coreutils 7.1.49-ebb9 FTB x86/Solaris

Tail of the build log below; what else would you like? make[3]: Entering directory `/home/install/gnu/build/i86_solaris/coreutils-7.1.49-ebb9/src' source='version.c' object='version.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \ cc -xc99=all -I. -I..

coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

Tail of the build log below; what else would you like? (I'm retrying the sparc build with the Sun compiler; you /don't/ want to know what version of gcc this is ;-). But I don't expect success due to AIX having what looks like the same problem.) sparc/Solaris source='fsusage.c' obj

coreutils 7.1.49-ebb9 FTB risc/HP-UX

Tail of the build log below; what else would you like? (I've *no* idea how to pass options from cc to cpp :-(. I had a similar problem with ncurses and was unable to figure it out; I ended up having to break up what cpp was seeing to get past it.) cc -g -o cp cp.o copy.o cp-hash.o libver.

Re: coreutils 7.1.49-ebb9 FTB x86/Solaris

Matthew Woehlke wrote: Undefined first referenced symbol in file MAX uname.o Ah, I just found <http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/16179> which is probably this issue. Any chance

Re: ready for a bug-fix coreutils-7.2?

Matthew Woehlke wrote: I just fired off builds of 7.1.49-ebb9 on ten platforms. Given that I think there is at least one non-c99 compiler in that mix, the results will probably be... interesting :-). (More-so because I expect failures due to 'make check' being run on a known-flaky

Irix nit

...lots of these, probably a missing/broken option check? (I'm curious why it wants to use a GNU option with the Irix (non-GNU) ld...) cc -c99 -g -Wl,--as-needed -o whoami whoami.o libver.a ../lib/libcoreutils.a ../lib/libcoreutils.a (null): WARNING 1 : Unknown option: -as-needed (ignore

Re: coreutils 7.1.49-ebb9 FTB x86/Solaris

Jim Meyering wrote: Matthew Woehlke wrote: Matthew Woehlke wrote: Undefined first referenced symbol in file MAX uname.o Ah, I just found <http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/16179>

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

Jim Meyering wrote: If someone cares enough about HP's C compiler, they teach autoconf to detect this limitation and automatically add an appropriate -H option, presumably to raise its internal limit. I'd love to help, but as mentioned, I have *no* idea how to feed options to cc so that it pas

7.1.xx test results

x86/Solaris is 7.1.63, all others from this run are 7.1.49 x86/Linux (RH4) 1 of 367 tests failed (47 tests were not run) FAIL: df/total-verify + perl -f check-df space Unrecognized switch: -f (-h will show valid options). + fail=1 + perl -f check-df inode Unrecognize

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

Jim Meyering wrote: It's saying that with its default settings, the post-cpp-expansion of this code is too large: [snip] I know what the problem is; as I was saying, I didn't find a way to get past this type of error except "don't do that", i.e. break down what cpp is seeing into manageable b

Re: 7.1.xx test results (ppc/Darwin 7.9.0)

Matthew Woehlke wrote: this run [is] 7.1.49 ppc/Darwin 7.9.0 6 of 367 tests failed (57 tests were not run) (I'm going to put these in a separate mail) All 116 tests passed (6 tests were not run) As promised... FAIL: chmod/no-x + chmod a-x . b + fail=1 + test 0 = 1 + f

Re: Irix nit

Jim Meyering wrote: Matthew Woehlke wrote: ...lots of these, probably a missing/broken option check? (I'm curious why it wants to use a GNU option with the Irix (non-GNU) ld...) If it doesn't cause any failure, it's not worth investigating or changing, since Irix is on the

Re: 7.1.xx test results

Jim Meyering wrote: This should fix it: Thanks, will test when I get a chance. -# Copyright (C) 2008 Free Software Foundation, Inc. +# Copyright (C) 2008-2009 Free Software Foundation, Inc. Nit: I thought GNU standard was "2008, 2009"? (But I could be getting mixed up with some other group

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

(Please don't miss the AIX error at the bottom that isn't another decl-after-stmt.) Jim Meyering wrote: Thanks for the report. That's a statement-before-decl: [snip] It's not be the only one. Ok, first, we'll try the patch: patching file remove.c Hunk #1 succeeded at 284 (offset 22 lines). H

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

Jim Meyering wrote: Matthew Woehlke wrote: Jim Meyering wrote: If someone cares enough about HP's C compiler, they teach autoconf to detect this limitation and automatically add an appropriate -H option, presumably to raise its internal limit. I'd love to help, but as mentioned,

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

Jim Meyering wrote: How about this instead? D'oh, collision with the other mail I was writing. Yes, that would be fine, or you can avoid the extra values all together by shifting parentheses to make it a binary search instead of linear. Actually my preference would be binary-search, since i

more 7.1.xx test results

More platforms... FBSD is 7.1.49, others are 7.1.63. risc/HP-UX 6 of 369 tests failed (115 tests were not run) FAIL: df/total-verify (perl -f error) FAIL: mkdir/selinux (same as ia64/HP-UX) FAIL: touch/dir-1 + fail=0 + touch . touch: setting times of `.': Is a directory

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

Jim Meyering wrote: Matthew Woehlke wrote: It's not be the only one. It's probably the only one in gnulib. True. Ok, first, we'll try the patch: patching file remove.c You're welcome to do this on your own, but it will take at least a few more requests to support

Re: coreutils 7.1.49-ebb9 FTB risc/HP-UX

Jim Meyering wrote: Jim Meyering wrote: Better, indeed. Would you like to prepare the patch? Oh, if you can't arrange for copyright assignments, ... So I've done this: [snip patch] Looks good, thanks again! (Will change if you ever add values :-) but shouldn't be hard to do. I might add a c

Re: new snapshot available: coreutils-7.1.71-e0149

Jim Meyering wrote: tests: df/total-verify: avoid test failure with older Perl Ironically, I might not be able to test this one. I expect perl's 'make check' to fail which will avoid it being installed on AIX; every other box now has 5.10.0 as I got sick of inconsistent, outdated, or ou

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

Eric Blake wrote: would be the wrong place to add it; POSIX only requires its definition in . And that is fortunate, since gnulib has not yet tackled sys/types but does have signal.in.h already. Does the first patch solve things for you? I can't test the configure part without first installi

avoid decl-before-stmt patch

Here's the patch I used to get my AIX build going. As noted previously, I do not have copyright assignment and am unlikely to be able to obtain it. (I'd also argue that - given that a trained monkey could produce this patch - it shouldn't be needed for this, but IANAL :-).) (Note: this would b

Re: new snapshot available: coreutils-7.1.71-e0149

Matthew Woehlke wrote: Jim Meyering wrote: tests: df/total-verify: avoid test failure with older Perl Ironically, I might not be able to test this one. I expect perl's 'make check' to fail which will avoid it being installed on AIX; every other box now has 5.10.0 a

Re: [PATCH] df: Fix bug when totaling unknown values.

Paul Eggert wrote: This fixes a bug reported by "make check" on a Solaris 10 host with some funky file systems. It was AIX ;-). * src/df.c (show_dev): Don't add UINTMAX_MAX to grand totals, as that value indicates that the true value is unknown; adding it effectively subtracts 1 from the tota

Re: [PATCH] df: Fix bug when totaling unknown values.

Jim Meyering wrote: Good timing. Matthew Woehlke recently reported failure of the df/total-verify test. Looking into it, we found that one of those values was UINTMAX_MAX - 1. Oops, I saw what the patch was and assumed you (Jim) sent it. Sorry for the confusion, Paul! (...that would explain

Re: [PATCH] df: Fix bug when totaling unknown values.

Paul Eggert wrote: + if (total != UINTMAX_MAX) Um... I've mentioned that this won't work, haven't I? AIX is (AFAICT) giving 0xFFF...FFE, not 0xFFF...FFF. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "We're all mad here. I'm mad. You're mad... You m

Re: [PATCH] df: Fix bug when totaling unknown values.

Paul Eggert wrote: Matthew Woehlke writes: Please do not quote my e-mail address unobfuscated in message bodies. :-) Paul Eggert wrote: + if (total != UINTMAX_MAX) Um... I've mentioned that this won't work, haven't I? AIX is (AFAICT) giving 0xFFF...FFE, not 0xFFF...F

coreutils-7.1.81-9b653 test results (was: new snapshot available)

This was interesting... 100% test success rate iff the hardware is x86. (A few of the failures are only in gnulib, however.) x86/Linux 370 pass, 55 skipped 122 pass, 12 skipped x86/Solaris 370 pass, 55 skipped 122 pass, 12 skipped sparc/Solaris (needs no-decl-afte

Re: coreutils-7.1.81-9b653 test results

Matthew Woehlke wrote: AIX 2 of 370 fail, 61 skipped 1 of 122 fail, 12 skipped (gnulib folks can skip the first two) FAIL: misc/printf.log (exit: 1) === + /home/install/gnu/build/rs6000_aix/coreutils-7.1.81-9b653/src/printf --version printf (GNU

gnulib build failure on risc/HP-UX (was: coreutils-7.1.81-9b653 test results)

Matthew Woehlke wrote: risc/HPUX (build failure) Here's the whole output, in case some of the warning are interesting (i.e. point to actual problems): make[3]: Entering directory `/tmp_mnt/home/install/gnu/build/hp700_hpux/coreutils-7.1.81-9b653/lib' make[4]: Entering

Re: coreutils-7.1.81-9b653 test results

Matthew Woehlke wrote: Irix 1 of 370 fail, 112 skipped 122 pass, 10 skipped (This one might be bogus...) FAIL: misc/sort-continue.log (exit: 1) == + sort --version sort (GNU coreutils) 7.1.81-9b653 Copyright (C) 2009 Free Software Foundation, Inc

Re: coreutils-7.1.81-9b653 test results

Matthew Woehlke wrote: ppc/Darwin 5 of 370 fail, 59 skipped 122 pass, 7 skipped FAIL: chmod/no-x.log (exit: 1) == + chmod --version chmod (GNU coreutils) 7.1.81-9b653 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or

Re: coreutils-7.1.81-9b653 test results

Matthew Woehlke wrote: ia64/HPUX 370 pass, 60 skipped 1 of 122 fail, 11 skipped (I think risc/HPUX has the same failure, but it failed to build; another gnulib problem, which I will post shortly.) FAIL: test-file-has-acl.sh.log (exit: 1

Re: coreutils-7.1.81-9b653 test results

Matthew Woehlke wrote: sparc/Solaris (needs no-decl-after-stmt patch) (gnulib test suite build failed due to decl-after-stmt) 370 pass, 54 skipped 1 of 122 fail, 5 skipped Not much to see here: FAIL: test-quotearg.sh.log (exit: 134) == test

Re: coreutils-7.1.81-9b653 test results

Matthew Woehlke wrote: Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew Woehlke on 3/26/2009 4:49 PM: sparc/Solaris Not much to see here: FAIL: test-quotearg.sh.log (exit: 134) == test-quotearg.c:182

Re: coreutils-7.1.81-9b653 test results

Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew Woehlke on 3/26/2009 4:49 PM: sparc/Solaris Not much to see here: FAIL: test-quotearg.sh.log (exit: 134) == test-quotearg.c:182: assertion failed Abort - core

Re: coreutils-7.1.81-9b653 test results

Eric Blake wrote: Matthew Woehlke users.sourceforge.net> writes: (Thanks, btw :-). ) sparc/Solaris Which version of Solaris? 2.7. (I think I'd mentioned that previously but you probably didn't see that message.) ...okay, trying again after

Re: new snapshot available: coreutils-7.1.86-9f39f

Jim Meyering wrote: One last snapshot before 7.2, just in case... Does this address any of the test failures in [1]? Or are you planning to release anyway? (For the record, I don't remember there being any failures that would keep me from installing 7.2 anyway, but I've seen almost zero foll

Re: new snapshot available: coreutils-7.1.86-9f39f

Jim Meyering wrote: Matthew Woehlke wrote: ...I've seen almost zero follow-up so far...) ??? Eric Blake spent quite a bit of time trying to reproduce and then diagnose your solaris 7 problem. Maybe you missed that. Sorry, I should have said "on most of the issues". Yes, Eric

Re: rm: cannot remove directory `coreutils-7.3/lib': Directory not empty

binutils wrote: I couldn't remove coreutils-7.3 directory after installation, even if using sudo. bash-4.0$ rm -rf coreutils-7.3/ rm: cannot remove directory `coreutils-7.3/lib': Directory not empty I've seen problems like that where 'chmod -R +w coreutils-7.3/' would fix it. (If that works,

Re: tail +n does not work under Linux?

Christophe LYON wrote: I have just noticed that 'tail +n' does not seem to work under Linux. For instance: $ tail +3 .cshrc tail: cannot open `+3' for reading: No such file or directory ==> .cshrc <== [...] I am using coreutils-7.2, and I have just reproduced the issue with 7.3, under Linux RH

Re: tail +n does not work under Linux?

Christophe LYON wrote: I am using coreutils-7.2, and I have just reproduced the issue with 7.3, under Linux RHEL 3 and 4. Also with Fedora 10's 6.12 package. The behavior change I think may have been in 6.0 (it is probably in the changelog). I do remember that change, but I also thought th

Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem

Chris Weston wrote: I'm trying debug an issue with my one of my disks in my system. I have an ext3 file system mounted and ls -l is reporting an impossible size for two of the files: log_1848_1239927341.core and log_1848_1239927341.core~. The size is 98P. This partition (/dev/sdb2) is only a few

Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem

James Youngman wrote: On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke wrote: Please do not quote my e-mail address unobfuscated in message bodies. Chris Weston wrote: I'm trying debug an issue with my one of my disks in my system. I have an ext3 file system mounted and ls -l is repo

Re: tail +n does not work under Linux?

Eric Blake wrote: COUNT runs into length problems - adding 4 characters per instance builds up fast. I'll try with NUM instead. As it is, I already had to rephrase things since "nth" is a word, but "count'th" and "num'th" are not. s/N/K/ ? :-) Is "K'th" item too awkward? (Or some other lett

Re: Human readable sort

Jim Meyering wrote: Maybe s/unambiguously/consistently/ or /uniformly/ and mention that it's the inconsistent precision that causes trouble. J. Random Bystander (i.e. me) prefers "consistently". ("Consistent", as in, using the same rules. "Uniformly" to me suggests maybe some

Re: Not sure how to best reply re: dir_colors situation

Pádraig Brady wrote: Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. If I can interject a question here... I hope I will remember to turn this back

Re: Not sure how to best reply re: dir_colors situation

Pádraig Brady wrote: Matthew Woehlke wrote: Pádraig Brady wrote: Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. If I can interject a question

Re: feature request: -0 option for tr

Bob Proulx wrote: Craig Sanders wrote: spaces and quote characters and even backslashes in filenames are far more common, especially on systems were files are uploaded by users from non-unix systems (e.g. ftp upload to web servers, samba file servers, etc) Yes. And cursed they are but so it i

Re: feature request: -0 option for tr

Bob Proulx wrote: Matthew Woehlke wrote: Bob Proulx wrote: Yes. And cursed they are but so it is. :-) Oh, come on. I know all about the "inherent danger", and I still use spaces in my file names, and probably always will. It's simply easier for us humans to think tha

Re: Enhacement request - 'date' util

Please use newlines and don't use HTML entities in text mail (or don't send HTML, if that was the problem). Your original mail looked like this: Good morning from Spain,first of all, thanks for your effort and for this rich featured tools... awesome work!Secondly, to the "date" command develope

Re: Enhacement request - 'date' util

Alejandro Redondo wrote: Hi again, sorry about those HTML characters... I sent the first email from a webmail client. And sorry about my bad English too, it's not my natal language. I didn't notice anything wrong with your English, actually :-). (Why is it, I wonder, that non-native speakers

Re: du counting files in hard-linked directories twice

Michael Schwarz wrote: The Problem I see as a bug is that, in some circumstances, du is counting the same files multiple times when they appear inside of hard-linked directories. Hard-linked *directories*? I wasn't aware those were allowed... (If I read 'man 3 link' right, they aren't allowed

Re: programs

Juhapekka Tolvanen wrote: On Thu, 31 Dec 2009, +14:51:44 EET (UTC +0200), Eric Blake pressed some keys: 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 siz

Re: programs

Juhapekka Tolvanen wrote: On Fri, 08 Jan 2010, +06:42:05 EET (UTC +0200), Matthew Woehlke wrote: Juhapekka Tolvanen wrote: On Thu, 31 Dec 2009, +14:51:44 EET (UTC +0200), Eric Blake pressed some keys: According to Juhapekka Tolvanen on 12/30/2009 4:35 PM: I wanted to do this: Give sizes of

[bug #15043] ls assigns colors inconsistently

Follow-up Comment #2, bug #15043 (project coreutils): FWIW, I have now tested on HP-UX (both 9000/800 and Itanium), Solaris (SPARC and x86), Tru64, AIX, and of course Linux (x86). Of the above, it is ONLY broken on Linux. ___ Reply to this

[bug #14352] GNU date (coreutils) -month does not work as expected

Follow-up Comment #1, bug #14352 (project coreutils): How is that unexpected? You asked for the 31'st day of 06 (June), which would be 0701 (July 1). ___ Reply to this item at:

[bug #17172] Problems building coreutils-5.97 on OSS (HP Nonstop)

URL: Summary: Problems building coreutils-5.97 on OSS (HP Nonstop) Project: GNU Core Utilities Submitted by: woehlkmp Submitted on: Friday 07/21/2006 at 23:50

[bug #15043] ls assigns colors inconsistently

Follow-up Comment #3, bug #15043 (project coreutils): Ok, I have tested a patch. In gobble_file, in the conditional starting 'if (command_line_arg' (the second 'if'), adding the condition '|| (type == directory && print_with_color)' fixes the problem, at least with the build I just did. Because t

[bug #17908] 'configure' fails because it is unable to determine how to read the mount table.

URL: Summary: 'configure' fails because it is unable to determine how to read the mount table. Project: GNU Core Utilities Submitted by: woehlkmp Submitted on: Wednesday 10/04/2006 at 00:43

[bug #17908] 'configure' fails because it is unable to determine how to read the mount table.

Follow-up Comment #2, bug #17908 (project coreutils): Yes, that would be the ideal, but until someone (maybe me, maybe not me) figures that out, is it not better to at least build the rest of coreutils without having to hand-edit configure and Makefile's?

Re: proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)

Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: In the midst of all these changes to printf-friends, is anyone (else) aware that the 'long long' suffix for the system printf on OSS is "L" ("ll" is not recognized)? That's news to me. I suppose we could configure it as well, though I'd

Re: coreutils-6.3: c89 patch insufficent

Michael Deutschmann wrote: coreutils-6.3 includes a patch, c99-to-c89.diff, to allow it to be compiled on platforms that don't support declarations after statements. However, this patch is not sufficent -- I had to fix two other areas to get coreutils to compile under GCC 2.95.3. I've appended m

Re: NSK(OSS) compilation problem

Paul Eggert wrote: Have you had a chance to look into the problems with long long shifts on NSK(OSS)? What happens if you compile and run the following program? Um, do you want the output from this? There is a LOT... almost 170k lines according to 'wc -l'. Or is there something I should be lo

Re: NSK(OSS) compilation problem

Paul Eggert wrote: Matthew Woehlke <[EMAIL PROTECTED]> writes: Um, do you want the output from this? There is a LOT... almost 170k lines according to 'wc -l'. Or is there something I should be looking for? That's very strange. There are only 87 lines on my platform. I

Re: NSK(OSS) compilation problem

Paul Eggert wrote: Matthew Woehlke <[EMAIL PROTECTED]> writes: Notice that it looks like the result of 'x>>y' under certain circumstances is '0x1 | (x & 0x)', regardless of the value of 'y'... which is of course Just Plain Wrong.

Re: du feature request

Logan Hansen wrote: I would like to request a feature to be added to the 'du' command: a command line switch to sort output by directory name or by size of directory option to sort by size... wow, that would be really nice. So nice I wrote this script to do it... du -B 1 "$@" | awk '{printf

Re: du feature request

Eric Blake wrote: According to Logan Hansen on 10/19/2006 12:10 PM: I would like to request a feature to be added to the 'du' command: a command line switch to sort output by directory name or by size of directory Why? What can we add to du that can't already be done by pipelining du output

Re: command "ls"

casper wrote: ls command sort options suggestion: 1. directories 2. files Um, are you looking for '--group-directories-first'? If not, you need to clarify your extremely vague suggestion. -- Matthew When on POSIX, do as POSIX mandates. ___ Bug-

Re: MD5SUM: False Negative

Eric Blake wrote: According to Gary Bartlett on 10/19/2006 5:14 PM: It appears that MD5SUM incorrectly lists some checks as FAILED when it should PASS, e.g. using the 32-bit TortoiseSVN distribution at http://tortoisesvn.net/downloads: Are you sure it's not a text vs. binary problem? Does 'md

Re: coreutils-6.4 released (stable)

Jim Meyering wrote: Coreutils version 6.4 has been released. If you haven't heard about the GNU coreutils, the FAQ is a good place to start: . This is a stable release. Changes since 6.3 have been solely to fix bugs and to improve portability and robu

Re: __long64_t not declared AIX 5.3.0.50, gcc 4.0.2

Paul Eggert wrote: Ville Laurikari <[EMAIL PROTECTED]> writes: I don't have the time to try to understand the philosophy behind all this "let's replace system headers with our own funky versions" stuff. Well, if we can't figure it out the "right" way, I guess we'll just have to patch it the "

Re: coreutils-6.4 released (stable)

Jim Meyering wrote: Matthew Woehlke <[EMAIL PROTECTED]> wrote: Jim Meyering wrote: Coreutils version 6.4 has been released. If you haven't heard about the GNU coreutils, the FAQ is a good place to start: <http://www.gnu.org/software/coreutils/faq/>. This is a stable release.

  1   2   3   >