Re: chown should catch null owner:group
LW> "chown -R ." gave an error Try DJ> chown -R . file which should emit "Holmes, you think you are changing the owner of FILE to be the same as the owner of ".", but you have actually typed something else (-R means recursive) which is an absolute error, about which the new improved chown command will hereby exit 1". ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
EB> `:' EB> ~ If only a colon is given, or if NEW-OWNER is empty, neither the EB> ~ owner nor the group is changed. OK, I'll drop my case, but please add a comment to this documentation about "why" or "who knows why?" or the motivation behind or uses of, this case. Perhaps "just to be orthogonal". Else people wonder what's up the sleeve. JM> I think it makes sense to diagnose a spec of "." as invalid. OK, you dudes take it from here. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
stat -f output standpoint
$ { stat .; stat -f .;}|grep File
File: `.'
File: "."
For the latter, shouldn't you say
Filesystem of "."
or
File: "/dev/hdz"
Else it's like your still talking about just the argument and not its
filesystem. stat (GNU coreutils) 6.10.
(P.S., you might enjoy writing `' instead of "", but it just leads to
cut and paste accidents sent to the shell, for me at least, about
twice a year. OK, never mind. I'm sure it's actually superior, etc.)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
stat info ls "total"
On the "stat" info page, at `--apparent-size' Print apparent sizes, rather than disk usage. The apparent size of a file is the number of bytes reported by `wc -c' on regular files, or more generally, `ls -l --block-size=1' or `stat ^the "total" line after each directory of Please add the above line, else people will 1. give a file and never see the "total" line, or 2. give a directory, but not know you are talking about the "total" line. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
stat --apparent-size
Also note that many people who are looking for --apparent-size style facilities are in fact looking for ways to find out which files have holes in them. The closest one can get to doing that might be something like $ find -type f -printf %S\\t%p\\n If there is a sure fire way, do add a note about it. OK, never mind. EB> You do realize that it is possible to create a custom LC_MESSAGES locale Ah, how sportive of you to break the news. A honeymoon with LC_MESSAGES in a romantic new locale. Oops, forgot my Geritol. Call in the coronerutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp -u vs. vfat's TWO seconds
Bad news fellows, regarding: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. Well it just so happens that the resolution on all(?) vfat flash cards, is TWO seconds, $ w3m -dump http://en.wikipedia.org/wiki/File_Allocation_Table | grep 2\ sec Note that the seconds is recorded only to a 2 second $ cd some/directory/on/my/vfat/flash_card $ stat *|perl -nwe 'm/^Modify:.*(\d\d)\.000/&&print " $1"'; echo 04 02 02 02 24 04 04 58 00 24 16 58 58 02 34 --all TWO seconds, (so they are always even numbers above.) This means that set /non-vfat/file /vfat/file $ cp -p $1 $2 #if done during an odd-numbered second of time, $ cp -u $1 $2 #will cause this second line to wastefully fire again. So please investigate your claim that the comparison is to the source time stamp truncated to the resolutions of the destination file system I bet that you never dreamed that you had to consider more than one second vs. fractional second differences. cp (GNU coreutils) 6.10 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
JM> It'd be great if you would suggest wording to document this discrepancy. The wording is fine as is. The problem is that you don't act according to your wording. You think "truncate fractional seconds, using one-second buckets to compare", whereas you need to use two-second buckets to compare if detected FAT, I suppose. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
JM> - document a subtle limitation encountered when using a losing file system It's the Lingua Franca of USB filesystem where I live. You change your comparison from Modify: 2008-04-03 05:45:22.7 to one second buckets Modify: 2008-04-03 05:45:22 so it should be just as easy to add a two second bucket too The Linux guys went through all the trouble to be able to write the file into the two second bucket, and they you fellows don't follow along: ah ha: GNU/Linux becomes GNU ... / ... Linux: a crack appears. Anyways, "all this to encourage you not to make your previous compliancy start to crack due to a moment of convenience". Or whatever. I'm having a vegi-burger. See ya. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
All I know is your program is guilty of conspiracy to wear out people's USB flash cards. If FAT is detected, just run source and destination times thru a chopper like $ m=$(date +%s); echo -n $m--\>; expr $m / 2 \* 2 1207175575-->1207175574 and cp -u will never blow it again, innocent of any future charges. JM> Don't blame Linux ;-) JM> This is due to the FAT specification. Different filesystems have different time granularities. Why draw an artificial line above one second just because it is unfamiliar? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls: sort on -s
I'm at the emacs' dired prompt, ls switches (must contain -l): -ogsS when I realized that -S is not good enough. What I want is an additional way to sort: on the -s sizes! > Just do ls -sog|sort -nr I hear you saying. But I can't. This is dired I'm in. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: sort on -s
> "JY" == James Youngman <[EMAIL PROTECTED]> writes: JY> On Wed, Apr 9, 2008 at 4:21 AM, <[EMAIL PROTECTED]> wrote: >> I'm at the emacs' dired prompt, >> ls switches (must contain -l): -ogsS >> when I realized that -S is not good enough. >> What I want is an additional way to sort: on the -s sizes! >> > Just do ls -sog|sort -nr >> I hear you saying. >> But I can't. This is dired I'm in. JY> Surely this is an Emacs issue. If we provide some kind of special JY> case in coreutils, the problem will still exist on platforms that JY> Emacs supports (many!) where the user is not running coreutils. James is right. Emacs' dired-sort-toggle-or-edit, "With a prefix argument you can edit the current listing switches instead" needs a more general method where one can pipe the results of a shell command instead of only being "allowed" to change some ls switches. (P.S., Gmane readers: I'm posting to both bug-gnu-emacs and bug-coreutils, which will trigger a gmane.org bug making this post not appear in the indexes of gmane's web interface.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -up forever
Fellas, in http://bugs.debian.org/276500 m> There is a new syscall in 2.6.22, utimensat. It gets a "struct timespec" m> which allows nanosecond resolution. That means you can now fix the difference in $ touch m; touch -r m n; stat -c %y m n 2008-06-24 06:13:24.106160298 +0800 2008-06-24 06:13:24.10616 +0800 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
document stty -g code positions
In (info "(coreutils)stty invocation"), please mention what all the secret codes in stty -g (--save) are. One could see e.g., right away that position 15 is different on my mom's terminal, but what stty setting is position 15, one asks? Otherwise one has to do e.g., COLUMNS=1 stty -a > /tmp/ww COLUMNS=1 stty -a -F /dev/tty1|diff - /tmp/ww to see what the differences are for two terminals. You can mention that the positions are version dependent, and not to be sent to one's friends expecting them to work. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls -s but sorted
ls man page says -s, --size print the size of each file, in blocks -S sort by file size but to sort by block size (not always the same as file size due to files with holes), one must do ls -s|sort -n ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -s but sorted
JY> What are you suggesting should be changed? There is no way to get any order into these rectangles I cropped from your reply: ~/tm tota 104K 12K 32K ~/tm tota 12 104 32 One must resort to an external program to get them in order. You only offer -S sorting, but we people trying to weed out torrent shrapnel want to order on the -s numbers. "So what, use an external program" you might say. But e.g., dired-sort-toggle-or-edit...With a prefix argument you can edit the current listing switches instead. doesn't allow one. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
terrible Unicode shattering fold(1) command
Problem 1: Here we see fold -s busy busting apart UTF-8 characters
again still.
Every third chop falls on a boundary, so is lucky.
No, I did not use `--bytes'. The result is the same as if I did anyway!
Problem 2: Also, when the critical chunk moves past the chopper blade, and we
now start
chopping ASCII, the UTF-8 chopping subsides, but it still chops NOT at
a blank, yes, that agrees with
`--spaces'
Break at word boundaries: the line is broken after the last blank
before the maximum line length. If the line contains no such
blanks, the line is broken at the maximum line length as usual.
but don't you see **you leave no option open to respect peoples words
and not bust them apart**. "So don't use the program" you might say.
Well, the program works nicely on 99% of the lines. Just please add an
option to also not bust apart peoples words no matter what!
$ env|egrep LC_\|LANG
LC_MESSAGES=C
LC_COLLATE=C
LANG=zh_TW.UTF-8
LC_CTYPE=zh_TW.UTF-8
$ cat t3
perl -lwe '
$w=q(曾昭媛 - 婦女新知基金會|0955-327898|02-2502-8715|[EMAIL PROTECTED]|秘書長);
for(0..11){$w=~s/z/zz/;print "echo \"$w\"|fold -s|iconv|wc -lc"}'|sh
$ sh t3
3 98
iconv: illegal input sequence at position 91
1 91
iconv: illegal input sequence at position 92
1 92
3 101
iconv: illegal input sequence at position 91
1 91
iconv: illegal input sequence at position 92
1 92
3 104
3 105
3 106
3 107
3 108
3 109
$ fold --version
fold (GNU coreutils) 6.10
fmt -s does not have this problem.
fold with no -s, and no -b or with -b also busts Unicode, use this
shortened test where the blade hits the critical area. Therefore we
see -b is stuck on, like it or not.
perl -lwe '
$w=q(曾昭媛 - 婦女新知基金會|0955-327898|02-2502-8715|[EMAIL PROTECTED]|秘書長);
for(0..11){$w=~s/z/zz/;print "echo \"$w\"|fold|iconv|wc -lc"}'|sh
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: terrible Unicode shattering fold(1) command
>> `--spaces' >> Break at word boundaries: the line is broken after the last blank >> before the maximum line length. If the line contains no such >> blanks, the line is broken at the maximum line length as usual. OR the line is not broken <-- new option, please add. JY> FWIW, that is hard in languages like Thai, where it's hard to Don't worry about all that, just detect ASCII SPACE and maybe TAB... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date validator
Regarding some RISKS postings that bear not so standard Dates, causing some browsing systems to read them as Jan 1 1970, etc., > "R" == RISKS List Owner <[EMAIL PROTECTED]> writes: R> How do we address this? We need to get every mailer in the world R> compliant... Well, we could pump all dates thru the very tolerant date --rfc-2822 -f to standardize them, but that would lose the colorful original timezone flavor. We could write a regexp to see if they match RFC 2822, etc. A web search shows some "date validator" matches... I know, let's forget the issue, but suggest to (CC'd) coreutils that they add a date --validate or --check functionality, like sort --check. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Uniq is so tilted to "first"
Uniq is so tilted to "first" $ man uniq|grep compar.*first avoid comparing the first N fields avoid comparing the first N characters $ man uniq|grep -c last 0 All so inflexible. There should be a more general way with ranges. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
test -t
On (info "(coreutils)File type tests", and test(1) man page, we see `-t FD' True if FD is a file descriptor that is associated with a terminal. Well please mention what happens if FD is omitted: $ test -t The answer is it always returns true, no matter what. Test with $ echo 'set -x; for i in 0 1 2 3 ""; do /usr/bin/test -t $i; : $?; done; tty'|at now; sleep 4; mail Same problem with the bash and dash builtin tests and documents. bash is even more freaky: $ t=test #bash builtin $ $t -t; echo $? 0 $ $t -t ''; echo $? 1 $ $t -t ' '; echo $? 0 $ t=/usr/bin/test $ $t -t; echo $? 0 $ $t -t ''; echo $? /usr/bin/test: invalid integer `' 2 $ dash $ t=test $ $t -t; echo $? 0 $ $t -t ''; echo $? test: 3: Illegal number: 2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date -u vs. CST
$ for i in E C M P; do for i in ${i}ST; do echo -n $i:; date -ud "7:00 $i";
done; done
EST:Wed Sep 3 12:00:00 UTC 2008
CST:Wed Sep 3 13:00:00 UTC 2008
MST:Wed Sep 3 14:00:00 UTC 2008
PST:Wed Sep 3 15:00:00 UTC 2008
$ for i in E C M P; do for i in ${i}ST; do echo -n $i:; date -d "7:00 $i";
done; done
EST:Thu Sep 4 20:00:00 CST 2008
CST:Thu Sep 4 07:00:00 CST 2008 <-UH OH
MST:Thu Sep 4 22:00:00 CST 2008
PST:Thu Sep 4 23:00:00 CST 2008
Why should the China zone kick in and out depending on -u? Note that I
object to it being interpreted differently in the input, not the
output.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
stat(1) badly needs flag to just print name of the symlink
Is it true that there is no stat(1) flag to just print the link name?
All one can find is
%N - Quoted file name with dereference if symbolic link
$ stat -c %N s1mp3.backup
`s1mp3.backup' -> `/mnt/extra10/s1mp3'
meaning the user must be dragged over the coals to do
$ stat -c %N s1mp3.backup |perl -F\'\|\` -anwle '{print $F[3]}'
/mnt/extra10/s1mp3
or
$ perl -wle 'print readlink($ARGV[0])' s1mp3.backup
/mnt/extra10/s1mp3
(P.S., I'm not talking about -L, --dereference.)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: stat(1) badly needs flag to just print name of the symlink
EB> What's wrong with readlink(1)? OK, I will let you off the hook if you enhance the stat(1) man page to please say something like: %N Quoted file name with dereference if symbolic link For just the dereference name, see readlink(1). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
quoted-printable en/decoder, to complement base64
There should be a quoted-printable en/decoder, to complement base64. Let's see what I was using for all these. #!/bin/sh -e #jidanni *** replacement for mime-codecs package *** case $0 in *qp-encode)perl -MMIME::QuotedPrint -wne 'print encode_qp($_)';; *qp-decode)perl -MMIME::QuotedPrint -wne 'print decode_qp($_)';; *base64-encode)perl -MMIME::Base64 -wne 'print encode_base64($_)';; *base64-decode)perl -MMIME::Base64 -wne 'print decode_base64($_)';; *)exit 88;; esac ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#353911: md5sum --check checks only if _all_ are bad
PS> Otherwise I'd like to hear the submitters opinion as well. The submitter leaves it all in your hands as I am not as sharp as I used to be. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#353911: md5sum --check checks only if _all_ are bad
JM> It should process every line. JM> My question was whether to emit a diagnostic for each _malformed_ line, JM> or just for the first or maybe the first few. Like cmp(1) bail out if any trouble perhaps, but have options for fuller digging/reports. OK, never mind... I leave it in your hands. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
stty doc 'enhancements'
On (info "(coreutils)stty invocation") say what you mean by Input Settings and Output Settings. I.e., what you type into the terminal and then goes into... what is sent from the computer to your terminal...?? After `iuclc' Translate uppercase characters to lowercase. Non-POSIX. May be negated. mention there is no corresponding item to Translate lowercase characters to uppercase. Same with lcase, say "ucase" is missing. Same at `olcuc' Translate lowercase characters to uppercase. Non-POSIX. May be negated. mention there is no 'ouclc' currently. (They all might be needed when trying to emulate some early computer system or something one day.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
git-diff shows none, even before ./bootstrap
Following the instructions in Reading README-hacking, $ ./bootstrap Error: 'autoconf' not found ... Well, rather then installing all those boring packages, I just skipped down to > At this point, there should be no difference between your local copy, > and the GIT master copy: >$ git diff > should output no difference. Ha ha, it shows no difference already, $ git-diff|wc 0 0 0 and you wanted to fool me into installing all those debs just to make a documentation patch! So README-hacking had better say better what the goal of those steps I skipped are. I mean, taking those steps could only make my perfect 0 0 0 less perfect. P.S. I used git-clone --depth 1 as you never know how big it will be without looking in the docs first, which you have to download first: http://article.gmane.org/gmane.comp.version-control.git/103218 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
say in ChangeLog-2008 why dead
In HACKING: No more ChangeLog files === Do not modify any of the ChangeLog files in coreutils. Starting in 2008, the policy changed. OK, but you better put a note about that at the top of ChangeLog-2008, else it looks like somebody died. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
better figure out a paperless copyright assignment method
Copyright assignment ...of an actual sheet of paper... Sorry, I'm on a non-USA Pacific island mountaintop with no paper business... anyway, got pictures of RMS and me on my website, so he'll have to vouch for me. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
HACKING doc git 3rd possiblity
In HACKING If you have made *no* changes: git pull If you *have* made changes and committed them to "master", do this: git fetch git rebase origin OK, but add If you *have* made changes but *have not* committed them to "master", do this: As to what "this" should be, well I don't know. All I know is "fetch", "committed to master"... must be some BDSM game :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] stty doc enhancements
---
doc/coreutils.texi | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 49aa16d..020dc51 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -11919,6 +11919,8 @@ Enable RTS/CTS flow control. n...@acronym{posix}. May
be negated.
@subsection Input settings
@cindex input settings
+These arguments specify input-related operations, i.e., bytes sent
+from your terminal to the computer are affected by them.
@table @samp
@item ignbrk
@@ -11991,7 +11993,9 @@ empty again. May be negated.
@opindex iuclc
@cindex uppercase, translating to lowercase
Translate uppercase characters to lowercase. n...@acronym{posix}. May be
-negated.
+negated. (Note no ilcuc is currently implemented, probably because one
+would not be able to use any more Unix commands, which are almost all
+lower case, after invoking it.)
@item ixany
@opindex ixany
@@ -12010,7 +12014,8 @@ when the input buffer is full. n...@acronym{posix}.
May be negated.
@subsection Output settings
@cindex output settings
-These arguments specify output-related operations.
+These arguments specify output-related operations, i.e., bytes sent
+from the computer to your terminal are affected by them.
@table @samp
@item opost
@@ -12021,7 +12026,7 @@ Postprocess output. May be negated.
@opindex olcuc
@cindex lowercase, translating to output
Translate lowercase characters to uppercase. n...@acronym{posix}. May be
-negated.
+negated. (Note no ouclc is currently implemented.)
@item ocrnl
@opindex ocrnl
@@ -12274,6 +12279,7 @@ as @code{tab3}.
@opindex lcase
@opindex LCASE
Same as @code{xcase iuclc olcuc}. n...@acronym{posix}. May be negated.
+(Note no ucase has been implemented.)
@item crt
@opindex crt
--
1.5.6.5
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] stty doc enhancements
All good except: PB> How about: PB> These settings control operations on data received from the terminal. PB> These settings control operations on data sent to the terminal. Remember that you need to locate the user between the two ends of something... One can't just imply. In each sentence you need to say what is the part nearest to them and what part is farthest from them somehow. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: better figure out a paperless copyright assignment method
Wait a second, when making a Wikipedia editing contribution we just click on a box below some licence statement. Why can't you guys use that method? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: better figure out a paperless copyright assignment method
> "EB" == Eric Blake writes: EB> According to jida...@jidanni.org on 12/18/2008 9:55 PM: >> Wait a second, when making a Wikipedia editing contribution we just >> click on a box below some licence statement. Why can't you guys use >> that method? EB> Why are you asking us, when we can't do anything to change the situation? EB> You should be asking the FSF licensing list: EB> ass...@gnu.org EB> http://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers Hmm, odd English there: "per". Hmm, kind of long. Anyway OK, CC'ing them to please mention in that document if "click through" agreements are useful at all. Anyway, good thing my contributions are always only few-liners. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
pathchk info page should mention other leading brand
$ info cor pathchk When I read this info page the question that one asks is "What about Windows? I want to know if I zip up some files and give them to my friend, will there be some problem when he unzips them on Windows?" So perhaps add after 3. A file name contains a character outside the portable file name character set, namely, the ASCII letters and digits, `-', `.', `/', and `_'. "So the filename should be portable to Windows, Mac..." (But not MS-DOS "8.3 names" of course.) Anyway, 2. The length of NAME is larger than the maximum supported by the operating system. 3. The length of one component of NAME is longer than its file system's maximum. but the OS would have warned us. A nonexistent NAME is not an error, so long a file with that name could be created under the above conditions. I see, it is for testing before making files on the current system... but then we could just do "touch FUNNY_NAME" and if we get an error message we will know usually... mainly we want to know if a file is portable to a foreign systems that we have no access to. OK, whatever. Do mention Windows... Also note that it writes to stderr, not stdout. Also mention that for each filename it bails out on the first error, # pathchk -p 123456789012345 pathchk: limit 14 exceeded by length 15 of file name component `123456789012345' # pathchk -p 123456789012345+ pathchk: nonportable character `+' in file name `123456789012345+' # pathchk -p 123456789012345+= pathchk: nonportable character `+' in file name `123456789012345+=' # pathchk -p 123456789012345=+ pathchk: nonportable character `=' in file name `123456789012345=+' so it can take multiple runs to find them all... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: pathchk info page should mention other leading brand
OK, but I would still say "By portability we are not talking about portability to other operating systems!" ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
No more "Your first commit: the quick and dirty way"
In the file HACKING, please remove the "Your first commit: the quick and dirty way". Just directly mention the right way, "Make your changes on a private "topic" branch" It only costs the user a couple more commands. Else you are starting many first time git users on the wrong foot; days of misery and twisted development habits that will take months to recover from mentally. $ grep -i never git/Documentation/*.txt ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
document sort -uf[r]
Regarding sort: `-f' `--ignore-case' Fold lowercase characters into the equivalent uppercase characters when comparing so that, for example, `b' and `B' sort as equal. The `LC_CTYPE' locale determines character types. OK, but also document this: $ echo -e 'A\na'|sort -uf A $ echo -e 'A\na'|sort -ufr A $ echo -e 'A\na'|sort -urf A The man page doesn't say what to expect. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Date can dish it out, but not parse it back in
Date can dish it out, but not parse it back in, for other languages: $ date 五 1月 16 00:49:11 CST 2009 $ date|date -f - 五 1月 16 00:00:00 CST 2009 $ LC_ALL=C date|date -f - 五 1月 16 00:49:26 CST 2009 $ locale LANG=zh_TW.UTF-8 LC_CTYPE=zh_TW.UTF-8 LC_NUMERIC="zh_TW.UTF-8" LC_TIME="zh_TW.UTF-8" LC_COLLATE=C LC_MONETARY="zh_TW.UTF-8" LC_MESSAGES=C LC_PAPER="zh_TW.UTF-8" LC_NAME="zh_TW.UTF-8" LC_ADDRESS="zh_TW.UTF-8" LC_TELEPHONE="zh_TW.UTF-8" LC_MEASUREMENT="zh_TW.UTF-8" LC_IDENTIFICATION="zh_TW.UTF-8" LC_ALL= $ date --version date (GNU coreutils) 6.10 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Date can dish it out, but not parse it back in
OK, better add after `-d DATESTR' `--date=DATESTR' Display the date and time specified in DATESTR instead of the current date and time. DATESTR can be in almost any common format. That it wants ASCII... P.S., nobody saw my http://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00051.html http://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00085.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] document sort --ignore-case --unique interaction
Signed-off-by: jidanni
---
doc/coreutils.texi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..06b259c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3742,6 +3742,10 @@ is a space or a tab, but the @env{LC_CTYPE} locale can
change this.
Fold lowercase characters into the equivalent uppercase characters when
comparing so that, for example, @samp{b} and @samp{B} sort as equal.
The @env{LC_CTYPE} locale determines character types.
+When used with @option{--unique} those lower case equivalent lines are
+thrown away. (There is currently no way to throw away the upper case
+equivalent instead. (Any @option{--reverse} given would only affect
+the final result, after the throwing away.))
@item -g
@itemx --general-numeric-sort
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Subject: [PATCH] date doc: warn at -d about LC_TIME
We also warn here about LC_TIME, so the user will know even if he
doesn't look in the @xref{Date input formats}.
Signed-off-by: jidanni
---
doc/coreutils.texi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..35d98b2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -13470,6 +13470,11 @@ format. It can contain month names, time zones,
@samp{am} and @samp{pm},
14:19:13.489392193 +0530"} specifies the instant of time that is
489,392,193 nanoseconds after February 27, 2004 at 2:19:13 PM in a
time zone that is 5 hours and 30 minutes east of @acronym{ut...@*
+Note: input currently must be in locale independent format. E.g., the
+LC_TIME=C below is needed to print back the correct date in many locales:
+...@example
+date -d "$(LC_TIME=C date)"
+...@end example
@xref{Date input formats}.
@item -f @var{datefile}
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils.texi too big
Gentlemen, it dawned on me. coreutils.texi is too big, from a source code management point of view. It should be broken down into logical parts, one for stty, one for sort, etc. Then you can pull it all together via @includes. Anyway, it makes no sense for e.g., edits to stty invocation to conflict with edits to sort invocation. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils.texi too big
EB> Care to submit a patch? (To tell you the truth I never tested my previous patches worked in textinfo or texinfo or whatever it's called :-) I just did monkey see monkey do) as you see somebody has to be in the ideas department, passing on ideas to the implementation experts... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH, resend] document sort --ignore-case --unique interaction
Signed-off-by: jidanni
---
No reply last time so resending.
doc/coreutils.texi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..06b259c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3742,6 +3742,10 @@ is a space or a tab, but the @env{LC_CTYPE} locale can
change this.
Fold lowercase characters into the equivalent uppercase characters when
comparing so that, for example, @samp{b} and @samp{B} sort as equal.
The @env{LC_CTYPE} locale determines character types.
+When used with @option{--unique} those lower case equivalent lines are
+thrown away. (There is currently no way to throw away the upper case
+equivalent instead. (Any @option{--reverse} given would only affect
+the final result, after the throwing away.))
@item -g
@itemx --general-numeric-sort
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH,resend] date doc: warn at -d about LC_TIME
We also warn here about LC_TIME, so the user will know even if he
doesn't look in the @xref{Date input formats}.
Signed-off-by: jidanni
---
Also no reply last time. Resending.
doc/coreutils.texi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..35d98b2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -13470,6 +13470,11 @@ format. It can contain month names, time zones,
@samp{am} and @samp{pm},
14:19:13.489392193 +0530"} specifies the instant of time that is
489,392,193 nanoseconds after February 27, 2004 at 2:19:13 PM in a
time zone that is 5 hours and 30 minutes east of @acronym{ut...@*
+Note: input currently must be in locale independent format. E.g., the
+LC_TIME=C below is needed to print back the correct date in many locales:
+...@example
+date -d "$(LC_TIME=C date)"
+...@end example
@xref{Date input formats}.
@item -f @var{datefile}
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -s documentation misleading
By the way, turning to -l, looking high and low on (info "(coreutils)What information is listed") doesn't say why ls follows symlinks, but ls -l doesn't: $ ls q f $ ls -l q lrwxrwxrwx 1 jidanni jidanni 1 2009-02-22 01:57 q -> z (Made with:) $ mkdir z $ touch z/f $ ln -s z q ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
must use cp && rm as mv has no --no-preserve
Gentlemen, I have discovered I must use cp && rm as mv has no --no-preserve. # touch k; mv k /cf mv: failed to preserve ownership for `/cf/k': Operation not permitted # touch k; cp -a --no-preserve=owner k /cf && rm k You see, moving to VFAT, one will get that message under different mount owners. And the only way to avoid it is my workaround. So do mention on the mv Info page this workaround for if you don't like 2>&-, and don't like warnings, but like -a. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls -l --show-me-each-link-in-the-symlink-chain
ls -l shows you the start of the symlink chain, ls -lL shows you the end of the symlink chain, but to see each link, one needs many ls -l's. There ought to be an option to see each link. Sure, there is usually just one link, but sometimes there is more. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -l --show-me-each-link-in-the-symlink-chain
> "EB" == Eric Blake writes: EB> According to jida...@jidanni.org on 3/25/2009 12:23 PM: >> ls -l shows you the start of the symlink chain, >> ls -lL shows you the end of the symlink chain, >> but to see each link, one needs many ls -l's. >> There ought to be an option to see each link. EB> readlink is what you're looking for. OK, please add a note to that effect at ls -L. And readlink needs an option to show each link in the chain! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
say when comm separator disappears
In (info "(coreutils)comm invocation"), after: With no options, `comm' produces three-column output. Column one contains lines unique to FILE1, column two contains lines unique to FILE2, and column three contains lines common to both files. Columns are separated by a single TAB character. The options `-1', `-2', and `-3' suppress printing of the corresponding columns. Also see *note Common options::. Please add: If two of them are used, the separator is no longer needed and will not be printed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bomb out quicker if cannot set date
$ date -s date: cannot set date: Operation not permitted Wed May 20 11:11:00 CST 2009 OK, then please don't print out that date afterward. Just bomb out. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Savannah report new bug link not obvious
Logged in to https://savannah.gnu.org/ the user cannot find the link to "report a new bug". ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
document or fix dangers of sort -u + any other option
Please fix the third command, $ echo -e 'a1\nb2\nc3\nb2'|sort -n|sort -u a1 b2 c3 $ echo -e 'a1\nb2\nc3\nb2'|sort -u|sort -n a1 b2 c3 $ echo -e 'a1\nb2\nc3\nb2'|sort -nu a1 or warn right there on the man page. Sure, you say -u, --unique with -c, check for strict ordering; without -c, output only the first of an equal run but still warn that the above will happen if one tries to combine anything with -u. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Savannah report new bug link not obvious
> "GS" == Giuseppe Scrivano writes: GS> jida...@jidanni.org writes: >> Logged in to https://savannah.gnu.org/ >> the user cannot find the link to "report a new bug". GS> Is https://savannah.gnu.org/bugs/?func=additem&group=coreutils the page GS> you are looking for? Ah, indeed it is. OK, all I know is when I browse https://bugzilla.wikimedia.org/ (logged in), there is a link "Enter a new bug" in the side panel. What you Savannah fellows need to do is add a similar link to your side panel. Yes, bugzilla then asks "First, you must pick a product on which to enter a bug.". So Savannah could do the same. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Savannah report new bug link not obvious
EB> Actually, for coreutils, we are just as happy with email bug reports (as Well do leave a path for those of us who have been toiled-trained by e.g., Bugzilla that the only real report is a browser generated report, and can't find the "Pavlov's dogs lever", http://en.wikipedia.org/wiki/Classical_conditioning (Do mention along the way that email reports are also fine.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#505927: just use the date(1) -d library instead of your own poorer date parser
> Regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505927 > "BSB" == Bernd Siggy Brentrup writes: BSB> Hi, BSB> I'm currently evaluating at's wishlist bugs for my 'at' replacement BSB> 'at-ng' which is a complete rewrite from scratch. Uh oh, "at no good"? :-) BSB> On Mon, Nov 17, 2008 at 05:49 +0800, jida...@jidanni.org wrote: >> Package: at >> Version: 3.1.10.2 >> Severity: wishlist >> >> At should be more flexible. Just use the date libraries instead of >> your own parser. >> $ at -v 'now + 5 years + 11 months' >> syntax error. Last token seen: + >> Garbled time >> $ date -d 'now + 5 years + 11 months' >> Fri Oct 17 03:53:15 CST 2014 >> However to get at to accept such a date, one needs: >> $ at -v $(date --rfc-3339=date -d 'now + 5 years + 11 months') >> Fri Oct 17 03:56:00 2014 >> warning: commands will be executed using /bin/sh >> If at would use the same library as date -d, you could 1. parse lots >> more types of dates. 2. Eliminate maintenance of duplicate code. BSB> If there only were such a library, static or preferrably dynamic! BSB> ldd /bin/date shows there is no dynamic one and dpkg -L coreutils shows BSB> no static version either. BSB> I might get coreutils sources and use the relevant parts but that BSB> deprives me of my freedom to choose a license at my will. IANAL but BSB> in my understanding using GPLed source code means you must release BSB> everything under the GPL. I'll Cc the coreutils people and thus hook you up so you fellows can figure out the best way to reuse code. I'm a big Stallman http://jidanni.org/comp/index.html#rms fan, so any license of his is good with me. BSB> I'm not yet decided what to do, in particular when thinking about BSB> i18n which may demand to cope with cultural differences. How does BSB> date handle these? I recall its output was better than its input, but then on your at(1) man page you can say "if at(1) can't parse Chinese dates yet, blame date(1)"! BSB> Regards BSB> Siggy BSB> [1] https://launchpad.net/~at-ng BSB> not much there for now, but by next week there will be BSB> demos for the cli commands at & friends. Server-side BSB> will take somewhat longer.
Re: Bug#505927: just use the date(1) -d library instead of your own poorer date parser
>> >> However to get at to accept such a date, one needs: >> >> $ at -v $(date --rfc-3339=date -d 'now + 5 years + 11 months') >> >> Fri Oct 17 03:56:00 2014 >> >> warning: commands will be executed using /bin/sh B'B> How do you like these: B'B> at-ng/build% ./at now + 5 years + 11 months B'B> Job will run at or after Wed, 29 Jul 2015 20:26:00 +0200. B'B> It was a trivial fix adding just 2 lines to the grammar. I'll cc them to let them know...
Re: Bug#505927: just use the date(1) -d library instead of your own poorer date parser
>>>>> "BSB" == Bernd Siggy Brentrup writes: BSB> Hi jidanni, BSB> I'm extremely angry about you forwarding my findings to the BSB> Debian BTS. Sorry. I just try to increase people's networking, and assumed the bug number, which I saw in the Subject, had fallen off the CC list and needed to be put back. So maybe I'm not the safest person to send things too. BSB> ps: Do you grant me permission to cite you to at...@free-it.org, BSB> which obviously is an address for at-ng related stuff? Yes, everybody can cite anything I say, it's all OK.
Bug#545721: info: No menu item `mktemp invocation' in node `(coreutils.info.gz)Top'.
X-debbugs-cc: bug-coreutils@gnu.org Package: coreutils Version: 7.5-3 Severity: minor $ man mktemp|col -b|grep -C 3 'info coreutils' The full documentation for mktemp is maintained as a Texinfo manual. If the info and mktemp programs are prop erly installed at your site, the command info coreutils 'mktemp invocation' should give you access to the complete manual. $ info coreutils 'mktemp invocation' 1>&- info: No menu item `mktemp invocation' in node `(coreutils.info.gz)Top'. P.S., the man page should say what directory the temp file ends up in if no options are given. Maybe it currently does but one has to look among the options to find out. Also mention what "Create a temporary file or directory, safely" means. Guaranteed not to overwrite any other existing file perhaps, and ...
quoted-printable [--decode]: it's time
OK, now that there is a base64(1) command, I could have sworn I also saw
a quoted-printable command too [or else I wouldn't have deleted mine so
fast :-(].
OK, I restored mine
$ cat bin/qp-decode
#!/bin/sh -e
#jidanni *** replacement for mime-codecs package ***
case $0 in
*qp-encode)perl -MMIME::QuotedPrint -wne 'print encode_qp($_)';;
*qp-decode)perl -MMIME::QuotedPrint -wne 'print decode_qp($_)';;
*base64-encode)perl -MMIME::Base64 -wne 'print encode_base64($_)';;
*base64-decode)perl -MMIME::Base64 -wne 'print decode_base64($_)';;
*)exit 88;;
esac
And as
$ apt-file search quoted-printable|wc -l
8
aren't coreutils, ("qp" finds even more), I hereby sure wish coreutils
had one.
Re: quoted-printable [--decode]: it's time
> "JM" == Jim Meyering writes: JM> GNU recode does that: JM> $ printf '\0\1'|recode ../QP Ah ha, then checkmate, $ recode -l|grep -i base64 /Base64 64 b64 I.e., you must either 1. Make a separate quoted-printable(1) command too, just to be fair. 2. Leave a note on the base64(1) man page saying that if one is looking for quoted-printable(1) try recode instead... however this isn't a good place to leave such a note... hmmm OK, whatever. I'll try to remember recode.
mv -v, cp -v messages should be different
Gentlemen, I object. The messages for these two commands should be different. $ cp -v f g `f' -> `g' $ mv -v f g `f' -> `g' Exactly how different etc. I leave up to you. Maybe even just => for the latter instead of ->.
Bug#565218: info boilerplate on man page gives only the hard way
X-debbugs-cc: bug-coreutils@gnu.org Package: coreutils Version: 8.1-1 Severity: wishlist We see many The full documentation for WHATEVER is maintained as a Texinfo manual. If the info and WHATEVER programs are properly installed at your site, the command info coreutils 'WHATEVER invocation' should give you access to the complete manual. Well, it turns out that we find we often can also just do $ info WHATEVER Therefore perhaps say info coreutils 'WHATEVER invocation or often just info WHATEVER or something like that.
Re: Bug#565218: info boilerplate on man page gives only the hard way
> "MS" == Michael Stone writes: MS> On Thu, Jan 14, 2010 at 06:00:17AM +0800, jida...@jidanni.org wrote: >> Well, it turns out that we find we often can also just do >> $ info WHATEVER MS> Yes, that's why it used to say that. But if something goes wrong with MS> info, that invocation will fall back to displaying the man page, and MS> then we get a bunch of bug reports complaining that the info page is MS> the same as the man page. So, that's why I suggested saying __both__ methods. But you already closed the bug before reading to the end.
tee|tee|tee
The tee(1) documents fail to say what happens when tee is given no arguments. Do say what is going on in $ echo o|tee|tee|tee o Also there is a Info reference to (bashref), but here on Debian there is no such match in apt-file(1).
Re: tee|tee|tee
> "GS" == Giuseppe Scrivano writes: GS> jida...@jidanni.org writes: >> The tee(1) documents fail to say what happens when tee is given no >> arguments. Do say what is going on in >> $ echo o|tee|tee|tee GS> "The `tee' command copies standard input to standard output and also to GS> any files given as arguments." GS> it looks quite clear to me, if you don't specify any file then stdin is GS> copied only to stdout. OK, then perhaps mention what actions are a no-op... as it all looks mysterious to beginners.
expr say "non integer argument"
$ expr 3.1 + 3 expr: non-numeric argument <---say "non integer argument" $ expr 3.1 + 3b expr: non-numeric argument
Re: expr say "non integer argument"
> "CFAJ" == Chris F A Johnson writes: CFAJ> On Thu, 18 Feb 2010, jida...@jidanni.org wrote: >> $ expr 3.1 + 3 >> expr: non-numeric argument <---say "non integer argument" >> $ expr 3.1 + 3b >> expr: non-numeric argument CFAJ>The expr command's arithmetic only works with integers. Yes CFAJ>3.1 is not an integer, nor is 3b. Yes CFAJ>To do calculations with decimal fractions, I recommend awk. Yes. 3,1 is numeric!
Re: expr say "non integer argument"
EB> jidanni, it would be a two-line patch to expr.c. Would you care to write EB> such a patch, rather than just complaining? It would be much more efficient for me to just play the role of the bug reporter here trust me. Thanks.
Re: expr say "non integer argument"
CFAJ> That'll teach me to post early in the morning! The problem is that you live in the incorrect timezone :-|
Re: expr say "non integer argument"
$ diff --git diff: unrecognized option '--git'<--see my next email coming soon. $ dlocate src/expr.c|wc 0 0 0 Actually at one point I was much more involved. http://article.gmane.org/gmane.comp.version-control.git/103400 However today its bash: git: command not found for me, as I'm intent on taking it easy.
diff "--git"
$ diff --git diff: unrecognized option '--git' I think diff should say at this point "real diff, at least up to year 2010, does not have a --git option, you are probably getting that idea from git output" or something. Or ask those git pros for a patch to give diff a --git option, or tell them that they are overstepping their bounds...
Re: diff "--git"
AMS> That is what it says, though not in so many words. Having an option AMS> for each VS would really be a headache (SCCS, RCS, CVS, hg, darcs, AMS> bzr, tla, git, ...). Well all I know is we then harangue the system administrator for not installing the latest diff that the other guys are already using... when in fact they are not using diff at all and diff --git would fail on their machine too because they have boldly invented a fantasy unlike any other seen there on the command line... So maybe there should be a general disclaimer added about some people spreading false rumors about diff options...
Re: -readable by who
Gentlemen, some of these are clearer than man test or (info "(coreutils) Access permission tests") bash$ help test|grep you -r FILETrue if file is readable by you. -w FILETrue if the file is writable by you. -x FILETrue if the file is executable by you. -O FILETrue if the file is effectively owned by you. -G FILETrue if the file is effectively owned by your group. Likewise, for find -readable, something should be done. > "JY" == James Youngman writes: JY> On Wed, Jan 13, 2010 at 11:06 PM, wrote: >> -readable >> Matches files which are readable... >> Also mention "by the current user" I suppose. JY> Since there is more than one possible interpretation of the "current JY> user" this clarification doesn't help much, I think.
you are not going to be able to sort this by the fifth field.
Try as you might, there is no way you are going to sort by this field, $ LC_CTYPE=zh_TW.UTF-8 w3m -dump \ http://www.tcb-bank.com.tw/tcb/servicesloc/atm_location/taichung_county_atm.htm | perl -anlwe 'print $F[4] if exists $F[4]'|LC_CTYPE=C sort without ripping it out of the table first using perl. Go ahead, try -t ... -k ...,... You won't be able to order that field in the same way one can after ripping it out of the table. sort (GNU coreutils) 8.4 P.S., perhaps add a --debug-fields mode which adds field boundary | pipe symbols into the output.
say that cut can't handle more than one field demarcator
On (info "(coreutils) cut invocation") please add: cut has no way to specify a group of blanks as a field demarcator. If you want that, use perl -a. Also use perl's split if you want regexp demarcators, etc. If that is indeed the case.
Re: you are not going to be able to sort this by the fifth field.
Thanks. I see I neglected the -b. On the info page in the `--field-separator=SEPARATOR' discussion, do mention the effects of -b on ' foo' etc. PB> $ LC_CTYPE=C sort --debug -sb -k5,5 < taichung_county_atm.htm (Use .txt, not .htms in examples.) Anyway, your --debug stuff would be clearer with just pipes added inline: $ echo 'a b c'|sort --debug=show_fields a| b| c or something like that.
Re: you are not going to be able to sort this by the fifth field.
EB> Except that you can specify overlapping keys. I find the idea of multiple EB> separate lines of underscores, one per key, much easier to follow in OK, any --debug=... is better than nothing.
Re: say that cut can't handle more than one field demarcator
> tr -s '[:blank:]' '\t' | cut -f5 And perhaps mention less painful tr -s \ \\t | cut -f5 and perl -anwle 'print $F[4]' if the user's input permits such simplification...
bug#7502: wc --verbose should say xx lines, yy words, zz characters
Idea: new option: --verbose $ wc --verbose should say xx lines, yy words, zz characters or xx lines yy words zz characters etc. With TAB separator too.
bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions
X-Debbugs-cc: bug-coreutils@gnu.org, bug-m...@gnu.org Package: coreutils Version: 8.5-1 man cp says: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. But it seems that isn't working too much/well, $ touch /tmp/f $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ ls -l --full-time f /tmp/f -rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.682527260 +0800 /tmp/f -rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.0 +0800 f $ mount /dev/sda6 on /home type ext3 (rw) tmpfs on /tmp type tmpfs (rw) It might work great f -> /tmp/f, but not the other way around. By the way, make(1) lacks any of this time comparison resolution machinery at all! I'll CC them.
bug#7568: stat 'i\i' shows 'i\\i'
stat 'i\i' shows 'i\\i'. Backspaces in filenames are doubled. stat (GNU coreutils) 8.5
bug#7618: man mktemp/[deprecated] clarification
man mktemp -p DIR use DIR as a prefix; implies -t [deprecated] -t interpret TEMPLATE as a single file name component, relative to a directory: $TMPDIR, if set; else the directory specified via -p; else /tmp [deprecated] It is not clear what is deprecated, -p, or both. Move [deprecated] closer to the front of the sentence. Or add a DEPRECATED OPTIONS section. Also I know the info page says why, but at -u, --dry-run do not create anything; merely print a name (unsafe) the reader thinks 'why, will it grind up my filesystem?' If --dry-run is unsafe, then I'd hate to try --wet-run. Say (unsafe to use for ).
bug#7877: sleep takes undocumented hex args
The documentation doesn't say that one can also use hex args: $ time /bin/sleep 0x10 real0m16.007s However not octal args: $ time /bin/sleep 010 real0m10.003s Maybe say how too.
bug#7877: sleep takes undocumented hex args
You see I was trying to make very special arguments to sleep so that I can make sure to kill the one I want pkill -u jidanni -fx sleep\ 22 It is not clear if that will still work. Maybe the man/info page should say a regexp that matches all valid args.
bug#7877: sleep 5 -4
$ sleep 5 -4 sleep: invalid option -- '4' $ sleep -- 5 -4 sleep: invalid time interval `-4' No fair prejudicing negative numbers. At least document it. 'However, GNU `sleep' accepts arbitrary floating point numbers (using a period before any fractional digits).' is what it says on Debian.
bug#7877: sleep 5 -4
> "PE" == Paul Eggert writes: PE> (Have I written enough to tempt ... to extend 'sleep' PE> to allow negative numbers? :-) Right you are young man. We here at NerdLabs already use $ sleep -- -100 to give us a few moments to go back and correct errors. But due to National Security, that's all I can say, except that one shouldn't make assumptions about what future generations might want to do...
bug#8241: Bug#618009: date: invalid date `TZ="America/Chicago" now' but Europe/Paris OK
Package: coreutils Version: 8.5-1 File: /bin/date X-debbugs-cc: bug-coreutils@gnu.org for i in Asia/Taipei America/Chicago America/New_York Europe/Paris do for j in monday now yesterday today tomorrow 12pm do echo TZ=\"$i\" $j; done; done|date -f - gives date: invalid date `TZ="America/Chicago" now' etc. ONLY when in America, and ONLY when using now etc. Monday etc. don't trigger the bug. By the way, America is undergoing a Daylight Savings Time jump right about now.
Re: mv: overwrite `/etc/lilo.conf', overriding mode 0644?
J> Thanks for the bug report, but 5.97 is very close to a year old. J> You're wasting your time testing it, I think, because many changes J> have been made since then. Please try a recent version of coreutils. J> (More generally, before reporting a bug in any piece of software, it J> is advisabel to verify that you are using a recent version). I see Debian sid is not as bleeding edge as I thought. Sorry, over and out. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
who(1) shows more than one user on the same terminal
Is it normal to see two users on the same tty? $ who jidanni pts/0 ... ralphpts/0 ... jim pts/1 ... $ ls -l /dev/pts/0 crw--w 1 jidanni tty 136, 0 2007-08-17 00:58 /dev/pts/0 The administrator (Dreamhost) says > You could potentially see many more than that at any given time. > There are other users with whom you share the hosting, as well as > the admins. This is normal. Yes, many users, but not on the same pts/0?! ps -u anybody_other_than_me won't show anything, so I can't investigate further. Perhaps "stale utmp entries?" ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: /usr/bin/test message forgets newline
JM> [note that only "[" accepts an OPTION. ] Ah, fine print. Land mine. JM> DESCRIPTION JM>Exit with the status determined by EXPRESSION. perhaps repeat the [note that only "[" accepts an OPTION. ] here. JM>--help display this help and exit JM>--version JM> output version information and exit ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
/usr/bin/test message forgets newline
/usr/bin/test neglects adding the trailing newline for this message at least: # /usr/bin/test -d 1 2 3 2>&1|od -c 000 / u s r / b i n / t e s t : e 020 x t r a a r g u m e n t ` 2 040 ' 041 P.S., $ /usr/bin/test --help $ /usr/bin/test --version do nothing, in contrast to the man page. (But not the Info page.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
wacko LC_ALL=zh_TW.utf8 egrep -i
$ printf Me\\nji\\n|LC_ALL=zh_TW.utf8 egrepMe\|ji Me ji $ printf Me\\nji\\n|LC_ALL=zh_TW.utf8 egrep -i Me\|ji ji $ printf Me\\nji\\n|LC_ALL=zh_TW.utf8 egrep -i Me Me $ printf Me\\nji\\n|LC_ALL=zh_TW.utf8 egrep -i me\|ji ji GNU grep 2.5.3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
fold UTF ready?
fold (GNU coreutils) 5.97 * counts bytes, not columns, even without -b * has no compassion for multibyte chars, turning UTF-8 into illegal sequences. export LC_ALL=zh_TW.utf8 echo 不准作台灣人|fold --help echo 不准作台灣人|fold -w 2 echo 不准作台灣人|fold -w 3 echo 不准 作台灣人|fold -w 3 echo 不准 作 台灣人|fold -w 3 echo 不准 作 台灣人|fold -w 3 -b echo 不准 作 台灣人|fold -w 3 -s echo 不准 作 台灣人|fold -w 4 -s ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: fold UTF ready?
> "EB" == Eric Blake <[EMAIL PROTECTED]> writes: EB> According to [EMAIL PROTECTED] on 10/13/2007 6:57 PM: >> fold (GNU coreutils) 5.97 EB> Consider upgrading. The latest stable coreutils is at 6.9. I'll tell Debian to upgrade. >> * counts bytes, not columns, even without -b >> * has no compassion for multibyte chars, turning UTF-8 into illegal >> sequences. EB> You've brought this up before, and the answer is the same as before. EB> Coreutils does not yet support multibyte locales, because no one has yet EB> contributed a patch that is usable across all the coreutils that handle EB> text, which is easy to maintain, and which does not penalize performance EB> on single-byte locales. OK, the --usage then should note it just means things like tabs when talking about columns, else it sounds like multibyte is supported. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
tail -n N
man tail -c, --bytes=N output the last N bytes -n, --lines=N output the last N lines, instead of the last 10 say -c N, --bytes=N etc. just like grep(1). P.S., For compatibility `tail' also supports an obsolete usage `tail -COUNT[bcl][f] [FILE]', which is recognized only if it does not conflict with the usage described above. COUNT is an optional decimal number optionally followed by a size letter (`b', `c', `l') to mean Mention it also doesn't work if more than one file is given: $ tail -1 aa aaa tail: invalid option -- 1 Try `tail --help' for more information. $ tail -1 aa Bla $ Version: Changelog here on Debian goes up to 2006-06-12 Paul Eggert <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
664 vs. touch -d now
Gentlemen, what's the deal, or have we been through this before and I'm just not using the current version or something here on Debian sid GNU/Linux 2.6.22. $ ls -al drwxr-xr-x 2 jidanni jidanni 60 2008-01-03 08:40 . drwxr-xr-x 3 jidanni jidanni 60 2008-01-03 08:23 .. -rw-rw-r-- 1 root jidanni 2 2008-01-03 08:35 a $ touch -d now a touch: setting times of `a': Operation not permitted $ touch a $ ls -l a -rw-rw-r-- 1 root jidanni 2 2008-01-03 08:41 a $ touch --version touch (GNU coreutils) 5.97 $ uname -a Also noticed with (which inspired me to send this bug): $ touch b $ cp -a b a cp: preserving times for `a': Operation not permitted Info says: If changing both the access and modification times to the current time, `touch' can change the timestamps for files that the user running it does not own but has write permission for. Otherwise, the user must own the files. Well at least: Ah ha, isn't "now" the current time? Bug! Muhahaha. Wait, you will pull out the fine print, fully aware I don't know how to change my screen resolution to read it (OK, can use xrandr), The strings `now' or `today' are relative items corresponding to zero-valued time displacement, these strings come from the fact a zero-valued time displacement represents the current time when not otherwise changed by previous items. They may be used to stress other... OK, OK, you win or whatever. As usual, I was... only trying to help. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 664 vs. touch -d now
Thanks for fixing it, as I don't want to get that deep... OK, Over and out. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
