Re: [PATCH] Re: date timezone question
Paul Eggert wrote: [EMAIL PROTECTED] writes: OK I've attached a patch that addresses question 1 above. Note this is not for merging, just for disussion really. The user-interface change sounds good cool, that's all I wanted to determine with the patch. but the implementation isn't quite right. I know. I'll have a look at cleaning it up. Note most of your points apply to the existing code, and I agree with them all. cheers, Pádraig. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failure tests/date/date-tests with current CVS
On Sun, May 09, 2004 at 08:44:36PM +0100, Ed Avis wrote:
> I configured and built the current CVS HEAD of coreutils, but 'make
> check' fails with
>
> make check-TESTS
> make[3]: Entering directory
> `/home/ed/cvs_working/coreutils/tests/date'
> ./date-tests: line 777: ./utc-1.I: No such file or directory
> ./date-tests: line 795: ./utc-1a.I: No such file or directory
> FAIL: date-tests
> ==
> 1 of 1 tests failed
> Please report to [EMAIL PROTECTED]
> ==
> make[3]: *** [check-TESTS] Error 1
>
> I am not sure what generates that file or why it is missing; it seems
> to be Test.pm but how?
Just an addition:
In order to make various tests succeed on a cvs checkout of
'COREUTILS-5_2_1' I had to do
#v+
touch tests/{cut,date,join,pr,tac,tail,test,tr,wc}/Test.pm
#v-
before running configure, make etc.
Regards,
Thomas
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: 'expr' and weird character classes
Hi Andreas :) * Andreas Schwab <[EMAIL PROTECTED]> dixit: > > returns 1, correctly. That is, 'expr' understands character > > classes but it needs that double bracket :( > The syntax of a character class is [:CLASS:], _including_ the brackets. > Thus to build a regular expression that matches a single lower case letter > or digit or underscore, you write "[[:lower:][:digit:]_]". You're right, I missed a paragraph in SUSv3: The character sequences "[." , "[=" , and "[:" (left-bracket followed by a period, equals-sign, or colon) shall be special inside a bracket expression and are used to delimit collating symbols, equivalence class expressions, and character class expressions. These symbols shall be followed by a valid expression and the matching terminating sequence ".]" , "=]" , or ":]" , as described in the following items. My fault, sorry for the idiocy :( > > and other binaries like 'tr' > `tr' doesn't expect regular expressions as arguments, but rather they are > interpreted as character sets without the surrounding brackets. True, and the worst thing is that I tested the following: $ echo "xalt" | grep "[:alpha:]" which obviously matches, but not because grep is interpreting the character class... is because that 'a' and 'l' in 'xalt'. My excuses, and sorry for the noise. Next time I'll read the standard with more attention :( You've been so kind for explaining, thanks a lot :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: cp by blocks, with errors
[EMAIL PROTECTED] (Bryan Henderson) wrote: > I have two (related) enhancements to cp to propose. Code is attached. > Enhancement 1: reading by blocks > Enhancement 2: handling of unreadable portions of source file ... > I can do some of this with dd if I'm desperate, but dd is technically > for a rather lower level job -- directly driving a device driver -- > not byte stream files. It doesn't for example, deal with short reads > in a byte stream way. Thank you for the patches. However, these are two fundamentally unrelated changes, so they should be considered separately. The first one looks like it's solely a performance optimization for the case (common?) in which there are short reads. Can you provide some data to justify adding this code? Do you have a feel for how often cp gets short reads when block alignment would make a significant difference in performance? The second looks like it'd be more appropriate as an option for dd than for cp, since dd already has a noerror option. Can you give an example showing why it'd be better to have this functionality in cp than in dd? Isn't it necessary sometimes to use lseek to get past an unreadable bit of media? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failure tests/date/date-tests with current CVS
Jim Meyering <[EMAIL PROTECTED]> writes: > You can work around the problem by removing all of the > *-tests files from your checked-out directory: > > rm `find tests -name '*-tests'` > > I've removed those (generated) files from CVS, > so they shouldn't cause any more trouble. I was about to report the same problem (after suffering from it for a few months -- I never got around to reporting it but somehow it bugged me this morning, what a coincidence!). It appears that your fix of removing *-tests from CVS has not been pushed out to me, but I just wanted to mention (in case you didn't notice already) a couple of things: 1. The file src/du-tests looks out of place. 2. The files tests/ls/ls-tests and tests/tr/range-tests are not removed by "make maintainer-clean"; is this intentional? I didn't remove them in my copy, as it wasn't necessary to remove them to fix the "make check" problem. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Unable to build current CVS: coreutils.pot not built
Ed Avis <[EMAIL PROTECTED]> writes: > shouldn't the configure script have a 'checking for gettext' stage? When you check source out directly from CVS, you're assumed to be an expert, and to have the correct build tools even if they're not on the standard list of tools all users are assumed to have. (The set of "expert" tools includes CVS itself. :-) The "checking for" stuff is designed more for non-experts, who are assumed to have tarballs instead of checking things out directly from CVS. It would be nice if it'd be easier to get things directly from CVS and that is on my list of things to help out with. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failure tests/date/date-tests with current CVS
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> You can work around the problem by removing all of the >> *-tests files from your checked-out directory: >> >> rm `find tests -name '*-tests'` >> >> I've removed those (generated) files from CVS, >> so they shouldn't cause any more trouble. > > I was about to report the same problem (after suffering from it for a > few months -- I never got around to reporting it but somehow it bugged > me this morning, what a coincidence!). It appears that your fix of > removing *-tests from CVS has not been pushed out to me, I've just run rsync. > but I just > wanted to mention (in case you didn't notice already) a couple of things: > > 1. The file src/du-tests looks out of place. It was good enough for my purpose, but it's not portable and not even reliable on my development system. I used it while revamping du to help ensure that my changes didn't have unwanted side effects. I suppose it belongs in tests/du/. > 2. The files tests/ls/ls-tests and tests/tr/range-tests are not > removed by "make maintainer-clean"; is this intentional? I didn't > remove them in my copy, as it wasn't necessary to remove them to fix > the "make check" problem. Those files deserved to be removed :-) ls/ls-tests was once generated, but hasn't been used for a long time tr/range-tests contained testing notes from 10 years ago. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Unable to build current CVS: coreutils.pot not built
Ed Avis <[EMAIL PROTECTED]> writes: > when I check out of CVS, am I getting a > slightly different code base from what goes into the tarballs? Yes, you're getting a subset of the tarballs. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Unable to build current CVS: coreutils.pot not built
On Sun, 9 May 2004, Andreas Schwab wrote: I got a clean checkout, configured with './configure' and tried to build with 'make'. The build fails with make coreutils.pot-update >>>You need to install gettext. >>But shouldn't the configure script have a 'checking for gettext' >>stage? > >It does, that's why xgettext is not called. Is it a bug that coreutils would not build after configuring? I expected that if an important component such as gettext were missing, it would report that and not write a makefile. -- Ed Avis <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Test failure tests/date/date-tests with current CVS
I configured and built the current CVS HEAD of coreutils, but 'make check' fails with make check-TESTS make[3]: Entering directory `/home/ed/cvs_working/coreutils/tests/date' ./date-tests: line 777: ./utc-1.I: No such file or directory ./date-tests: line 795: ./utc-1a.I: No such file or directory FAIL: date-tests == 1 of 1 tests failed Please report to [EMAIL PROTECTED] == make[3]: *** [check-TESTS] Error 1 I am not sure what generates that file or why it is missing; it seems to be Test.pm but how? -- Ed Avis <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Unable to build current CVS: coreutils.pot not built
On Sun, 9 May 2004, Andreas Schwab wrote: >>I got a clean checkout, configured with './configure' and tried to >>build with 'make'. The build fails with >> >>make coreutils.pot-update >>make[4]: Entering directory `/home/ed/cvs_working/coreutils/po' >>: --default-domain=coreutils --directory=.. \ > >You need to install gettext. OK, I'll try that. But shouldn't the configure script have a 'checking for gettext' stage? -- Ed Avis <[EMAIL PROTECTED]> ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
'expr' and weird character classes
Hello all :) I'm using coreutils 5.2.1 and I've noticed a weird behaviour of 'expr'. I don't know if it's my fault, but a command like: $ expr "x" : "[:alpha:]" returns 0 instead of 1, but a command like: $ expr "x" : "[[:alpha:]]" returns 1, correctly. That is, 'expr' understands character classes but it needs that double bracket :( This is non portable AFAIK, at least is not SUSv3 compliant regarding basic regular expressions, and other binaries like 'tr' or 'grep' correctly use the single bracket character classes. Am I doing something wrong? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
cp by blocks, with errors
I have two (related) enhancements to cp to propose. Code is attached. Enhancement 1: reading by blocks Reading and writing of files is typically fastest and most efficient when you read or write blocks of a certain size. cp seems to understand this in that it uses the block size (according to stat()) of the source file as the buffer size for its copy. But cp makes only a feeble attempt to read whole blocks. If a read is short for any reason (the operating system is free to return less than the requested size any time it wants), all future reads are out of sync with the file's blocks. Also, the size returned by stat() isn't necessarily the best size. Modern filesystems are much more complicated than can be described by a single number like that. My enhancement is 1) add a --readsize option so the user can choose the buffer size. It still defaults to the stat() block size. 2) keep the reads synchronized to a multiple of the read size by filling in short reads. E.g. If a 4K read returns 3K, cp does a 1K read to resynchronize to a 4K boundary. This is a minor change to the code -- it just involves replacing the file read call with a subroutine that loops until it gets it all. Enhancement 2: handling of unreadable portions of source file - Today, if cp encounters an unreadable stretch of file, it just quits. I have added two new alternatives, controlled by the new --errors option. In both, cp searches ahead in the file until it finds a readable portion. With --errors=zero, cp pretends it read zeroes in place of the unreadable portion. With --errors=skip, cp pretends the unreadable bytes just didn't exist; the resulting file is shorter than the source. Another new option, --errorgrain, tells how finely cp searches for the end of the bad area; it is the step size by which cp seeks forward, trying a read at each step. Default is 512 bytes. cp issues warnings at the end of each file copy telling how much data was lost. This is mostly just embellishment of the new read subroutine I mentioned above. There's also the option handling and the statistics reporting, but no structural changes to the existing copy logic. Purpose of error handling - I need this because I have large cpio backup files that sometimes have media errors. A single sector is missing here and there from the file. I want to copy the file to a good disk and proceed to salvage all the data inside the backup file that is not affected by the missing sectors. cpio can generally resynchronize quite well if data after the error remains at the same offset, so I use cp --errors=zero. I can do some of this with dd if I'm desperate, but dd is technically for a rather lower level job -- directly driving a device driver -- not byte stream files. It doesn't for example, deal with short reads in a byte stream way. I have other backup volumes that contain full images of the original filesystem; I restore those using cp --archive. Again, if a single sector somewhere is bad, I'd rather have the cp complete on all the other files, and whatever it could save of the ruined file, than have to manually sort through the thousands of files in that directory and work around the bad ones. -- Bryan HendersonPhone 408-621-2000 San Jose, California cperror.patch Description: Binary data ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
uniq -c chokes on international characters
To whom it may concern, After executing a uniq on a list of names, some of which contain accent characters, I noticed that the lines with acccent characters were not being consolidated into a non-repeating pattern. For instance, the following is sampling of the output of a command line which counts the unquie posters to the nessus-devel list and their corresponding number of posts. 1 Luca Andreucci 1 Maciej Soltysiak 1 Marc Spitzer 1 Mark Curphey 1 Martin Maèok 1 Martin Maèok 1 Martin Maèok 1 Martin Maèok 1 Martin Maèok 1 Martin Maèok 1 [EMAIL PROTECTED] 1 Matt Petteys Below is yet another sampling, which made me realize the issue: 1 Guillaume Valadon 1 gzhe2001 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Javier Fernández-Sanguino Peña 1 Jay 1 Jay Jacobson uniq --version uniq (coreutils) 4.5.3 -Jimmy Alderson ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failure tests/date/date-tests with current CVS
Ed Avis <[EMAIL PROTECTED]> wrote: > I configured and built the current CVS HEAD of coreutils, but 'make > check' fails with > > make check-TESTS > make[3]: Entering directory > `/home/ed/cvs_working/coreutils/tests/date' > ./date-tests: line 777: ./utc-1.I: No such file or directory > ./date-tests: line 795: ./utc-1a.I: No such file or directory Thanks for reporting that. You can work around the problem by removing all of the *-tests files from your checked-out directory: rm `find tests -name '*-tests'` I've removed those (generated) files from CVS, so they shouldn't cause any more trouble. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: uniq -c chokes on international characters
[EMAIL PROTECTED] wrote: > To whom it may concern, > After executing a uniq on a list of names, some of which contain > accent characters, I noticed that the lines with acccent characters were > not being consolidated into a non-repeating pattern. For instance, the > following is sampling of the output of a command line which counts the > unquie posters to the nessus-devel list and their corresponding number > of posts. > > 1 Luca Andreucci > 1 Maciej Soltysiak > 1 Marc Spitzer > 1 Mark Curphey > 1 Martin Maèok > 1 Martin Maèok > 1 Martin Maèok > 1 Martin Maèok > 1 Martin Maèok > 1 Martin Maèok > 1 [EMAIL PROTECTED] > 1 Matt Petteys > > uniq --version > uniq (coreutils) 4.5.3 Thanks for the report. I cannot reproduce the problem using uniq from coreutils-5.2.1. 4.5.3 is a bit old. Would you please get coreutils-5.2.1 and try that? ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.bz2 ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: 'expr' and weird character classes
DervishD <[EMAIL PROTECTED]> writes: > Hello all :) > > I'm using coreutils 5.2.1 and I've noticed a weird behaviour of > 'expr'. I don't know if it's my fault, but a command like: > > $ expr "x" : "[:alpha:]" This matches "x" against the set of characters ":ahlp". > returns 0 instead of 1, but a command like: > > $ expr "x" : "[[:alpha:]]" This matches "x" against the set of characters from the character class "alpha". > returns 1, correctly. That is, 'expr' understands character > classes but it needs that double bracket :( The syntax of a character class is [:CLASS:], _including_ the brackets. Thus to build a regular expression that matches a single lower case letter or digit or underscore, you write "[[:lower:][:digit:]_]". > This is non portable AFAIK, at least is not SUSv3 compliant regarding > basic regular expressions Please read again. > and other binaries like 'tr' `tr' doesn't expect regular expressions as arguments, but rather they are interpreted as character sets without the surrounding brackets. > Am I doing something wrong? You are mixing the syntax for a regular expression containing a character set with the syntax for a character class inside a character set. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
