bug#28079: Fwd: bug#28079: find -type l -xtype and recursive symbolic links
-> findutils bug https://savannah.gnu.org/bugs/index.php?51926
bug#9102: timeout 0 FOO should timeout right away
2011/7/17 Paul Eggert egg...@cs.ucla.edu: On 07/17/11 05:31, Pádraig Brady wrote: Well my reasoning for having 0 mean don't timeout, was to have an easy way in scripts to specify no timeout That's a good thing to have, but it could be specified in a different way. One possibility is the '1' (digit 1) option, e.g., timeout -1 FOO. Or if that's too clever, we could use some other letter for the option. I'm not sure that's worked out so well for tail. But if we are looking for an argument indicating we don't want a timeout, the argument never is quite clear. James.
bug#9102: timeout 0 FOO should timeout right away
2011/7/19 Pádraig Brady p...@draigbrady.com: On 19/07/11 23:00, James Youngman wrote: 2011/7/17 Paul Eggert egg...@cs.ucla.edu: On 07/17/11 05:31, Pádraig Brady wrote: Well my reasoning for having 0 mean don't timeout, was to have an easy way in scripts to specify no timeout That's a good thing to have, but it could be specified in a different way. One possibility is the '1' (digit 1) option, e.g., timeout -1 FOO. Or if that's too clever, we could use some other letter for the option. I'm not sure that's worked out so well for tail. But if we are looking for an argument indicating we don't want a timeout, the argument never is quite clear. I don't follow (pardon the pun). This will sleep(0) between polls which takes 10% of my cpu here: tail ---disable -s0 -F nosuch Sorry about the lack of clarity. I was referring to the mess over tail -n 30, tail -30, tail +30 etc. and more specifically was trying to indicate that I didn't think timeout -0 would be a useful direction, for that reason. I'd suggest that Paul's shell snippet could usefully be: timeout=never [ $platform = buggy ] timeout=10 timeout $timeout command James. -- This email is intended solely for the use of its addressee, sender, and any readers of a mailing list archive in which it happens to appear. If you have received this email in error, please say or type three times, I believe in the utility of email disclaimers, and then reply to the author correcting any spellings (and, optionally, any incorrect spellings), accompanying these with humorous jests about the author's parentage. If you are not the addressee, you are nevertheless permitted to both copy and forward this email since without such permissions email systems are unable to transmit email to anybody, intended recipient or not. To those still reading by this point, the author would like to apologise for being unable to maintain a consistent level of humour throughout this disclaimer. Contents may settle during transit. Do not feed the animals.
bug#8930: $date +%C
2011/6/24 Dimitri Tassiaux d.tassi...@gmail.com: *Century error !* This isn't a very intelligible bug report. When reporting a bug in software please state as precisely as possible: 1. What you did. 2. What you expected to happen. 3. What actually did happen. In this case I assume you think that %C prints the century, for example 21. It turns out that it doesn't. From the documentation: %C century; like %Y, except omit last two digits (e.g., 20) I agree though that using the word century here is misleading. date (GNU coreutils) 8.5 Copyright © 2010 Free Software Foundation, Inc. License GPLv3+ : GNU GPL version 3 ou ultérieure http://gnu.org/licenses/gpl.html Ceci est logiciel libre, vous êtes libre de le modifier et de le redistribuer. Ce logiciel n'est accompagné d'ABSOLUMENT AUCUNE GARANTIE, dans les limites autorisees par la loi applicable. Écrit par David MacKenzie.
bug#8782: date command
On Thu, Jun 2, 2011 at 10:11 AM, Jim Meyering j...@meyering.net wrote: Pádraig Brady wrote: OK how about I put the last 3 or 4 examples from http://www.pixelbeat.org/cmdline.html#dates in an EXAMPLE section in the man page. Good examples. I like the idea. One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. James.
bug#7320: 'group' command gives wrong/extra group
Does the same thing happen with id -G?
bug#5861: [PATCH] Explain what makes a 'word' as counted by wc.
--- src/wc.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/wc.c b/src/wc.c index 0698ae1..6df7fed 100644 --- a/src/wc.c +++ b/src/wc.c @@ -117,7 +117,8 @@ Usage: %s [OPTION]... [FILE]...\n\ fputs (_(\ Print newline, word, and byte counts for each FILE, and a total line if\n\ more than one FILE is specified. With no FILE, or when FILE is -,\n\ -read standard input.\n\ +read standard input. A word is a non-zero-length sequence of characters\n\ +delimited by white space.\n\ -c, --bytesprint the byte counts\n\ -m, --charsprint the character counts\n\ -l, --linesprint the newline counts\n\ -- 1.7.0
Re: rm (remove.c): Rewrite to use fts: request for review
On Fri, Aug 28, 2009 at 7:09 PM, Jim Meyeringj...@meyering.net wrote: Here's an interesting patch. [...] It'd be great if another pair of eyes could glance through these changes (diffs look big, but most hunks are simply removals). I read the patch, but don't have any comments. Partly this is because it is hard to get a sense of the new flow of the code by reading the patch only. I'd have to apply it and read the result, really. I will try to find time to do that too. James.
Re: [RFC] new open flag O_NOSTD
On Mon, Aug 24, 2009 at 1:22 PM, Eric Blakee...@byu.net wrote: The name proposed in this mail is O_NOSTD (implying that a successful result will not be any of the standard file descriptors); other ideas mentioned on the bug-gnulib list were O_SAFER, O_NONSTD, O_NOSTDFD. http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00358.html Thoughts? Mostly yes, I like it. I'd like to explicitly vote against O_SAFER, because there may be (for some systems or in the future) some other way of making open(2) safer. I'd vote positively for O_NOSTDFD or O_NOSTD. James.
Re: Bug#539481: coreutils: [df] Please use DOT instead of COMMA in -h (human readable) size listing
On Sat, Aug 1, 2009 at 10:58 AM, Jari Aaltojari.aa...@cante.net wrote: Package: coreutils Version: 7.4-2 Severity: wishlist [Debian Bug / wishlist] $ df -hl | grep usb /dev/sdb1 3,9G 3,9G 96K 100% /media/usb0 /dev/sdc1 3,8G 4,0K 3,8G 1% /media/usb1 SUGGESTION Please prefer representing fractional values in computer-dot notation: /dev/sdb1 3.9G 3.9G 96K 100% /media/usb0 /dev/sdc1 3.8G 4.0K 3.8G 1% /media/usb1 But you chose to use the comma yourself - by selecting your locale. If you want to use . as the decimal radix marker, just delect an appropriate locale: $ LC_ALL=C df -h . FilesystemSize Used Avail Use% Mounted on /dev/mapper/mirror_a-home 9.9G 7.8G 1.6G 84% /home $ LC_ALL=es_ES df -h . S.ficheros Tama�o Usado Disp Uso% Montado en /dev/mapper/mirror_a-home 9,9G 7,8G 1,6G 84% /home $ LC_MESSAGES=es_ES LC_NUMERIC=C df -h . S.ficheros Tamaño Usado Disp Uso% Montado en /dev/mapper/mirror_a-home 9.9G 7.8G 1.6G 84% /home $ man locale ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Porting GNU Projects - Coreutils
On Wed, Jul 29, 2009 at 4:16 PM, bornlibra23awari...@nse.co.in wrote: Hello People I am trying to port various GNU products to Stratus OpenVOS platform including the GCC compiler collection. However I am stuck currently for the lack of wide multibyte character support. Can somebody guide me to an implementation of the same that I can port first. According to http://www.stratus.com/products/openvos/index.htm the OpenVOS system is POSIX compliant, so it must already have multibyte character support, I think. However, I guess it may not support all the locales you would like. The glibc is also proving a monster to port for various reasons. But there must already be a system C library, surely, if the system is POSIX compliant. I have tried to build the wide character support of glibc separately but it didnt workout. Can somebody isolate the code guide me in implementing it on VOS? This is proving to be a major blocker. Please help Thanks bornlibra23 checking for BEOS mounted file system support functions... no checking whether it is possible to resort to fread on /etc/mnttab... no configure: error: could not determine how to read list of mounted file systems bash-2.05$ I can't help notice that this failure message seems to have nothing whatsoever to the problem you wrote about above. Perhaps I am confused. -- View this message in context: http://www.nabble.com/Porting-GNU-Projects---Coreutils-tp24721478p24721478.html Sent from the Gnu - Coreutils - Discuss mailing list archive at Nabble.com. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: _cache-open()failured
On Mon, Jul 20, 2009 at 8:25 PM, Bob Proulxb...@proulx.com wrote: Bernhard Herko wrote: Mayby there is someone who can help me. Maybe, could you let us know how you came to send email to the bug-coreutils mailing list? Maybe there is some documentation pointing to it that needs to be updated so that it is more helpful. Could you let us know where you found the email address? You have reached the GNU Coreutils mailing list. The GNU Coreutils are the basic file, shell and text manipulation utilities of the GNU Operating System. You can learn more about GNU Coreutils here: http://www.gnu.org/software/coreutils/ The GNU Coreutils are part of the GNU Operating System. You can learn more about the GNU Project here: http://www.gnu.org/ But you are asking about a system upgrade problem. I am sorry but this is the wrong mailing list. We don't know anything about Ubuntu here. Nor dpkg. We are unable to help you here. Send report is my computer writing, when you see the messige above. I search the net and try: sudo dpkg --configure -a, apt-get update, apt-get upgrade and then my computer write to me: _cache-open() failured, please report.. Is there someone Who can help me. Iḿ using 9.04 Jaunty... Since you are using Ubuntu then the Ubuntu users mailing lists would be a better source of information. http://www.ubuntu.com/support/communitysupport http://www.ubuntu.com/support/community/mailinglists Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug when installing gnome-do plugins?
On Tue, Jul 14, 2009 at 3:41 PM, Daygan Sobotkasheerz...@gmail.com wrote: When attempting to install gnome-do plugins on my 64-bit Ubuntu O.S. I run into this problem First, thank you for including both the background information and the precise output you saw. This is very helpful. at the sudo make install command: /usr/bin/install -c -d //usr/local/lib/gnome-do/plugins /usr/bin/install -c -m 644 -t //usr/local/lib/gnome-do/plugins /usr/bin/install: missing file operand Try `/usr/bin/install --help' for more information. make[3]: *** [install-data-hook] Error 1 The install command needs two non-option arguments; the file you want to install and the location in which you want to install it. In this case you can see that the install command only gets one non-option argument. Interestingly, the single argument seems to be the destination, not the thing to install. I can only assume from the above that the Makefile finds that it has no data files that it wants to install in //usr/local/lib/gnome-do/plugins. Unfortunately, the coreutils folks only write the program called install. We don't know what the gnome-do maintainers put in their Makefile, or why. My guess at this stage is that you didn't do anything wrong, you're just seeing a bug (or perhaps a portability problem) in the Makefile. I suggest that you take this up with the authors of gnome-do-plugins-0.8.2. I don't know how you would contact them, but I'm sure that the package comes with a README file telling you where you can get help. As for the remaining messages you included (quoted again below), they simply indicate that after make experienced the failure shown above, it stopped. It was useful for you to include them, but in this case they don't tell us much extra information (except for telling me the name of the package you are trying to install). make[3]: Leaving directory `/home/daygan/Desktop/gnome-do-plugins-0.8.2/BundledLibraries' make[2]: *** [install-data-am] Error 2 make[2]: Leaving directory `/home/daygan/Desktop/gnome-do-plugins-0.8.2/BundledLibraries' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/daygan/Desktop/gnome-do-plugins-0.8.2/BundledLibraries' make: *** [install-recursive] Error 1 I'm really not certain if this is a bug or just something due to an error on my own part.. but I thought I'd report it just in case. If you have any suggestions for me to correct this issue, they would certainly be welcome. I think it may well be a bug in the Makefile, as I mentioned earlier. Check the README file that came with it to figure out how to contact the gnome-do-plugins-0.8.2 folks. Sorry I couldn't directly solve your problem, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls manpage incomplete
On Thu, Jul 9, 2009 at 9:57 PM, Richard Guy Briggsr...@tricolour.net wrote: The ls(1) manpage is incomplete. Why? On Fri, Jul 10, 2009 at 4:29 AM, Richard Guy Briggsr...@tricolour.net wrote: On Thu, Jul 09, 2009 at 08:42:15PM -0600, Eric Blake wrote: According to Richard Guy Briggs on 7/9/2009 2:57 PM: The ls(1) manpage is incomplete. Why? No, I don't want to use info(1). GNU coreutils 6.10 April 2008 Consider upgrading - the latest stable version is 7.4. That said, the man pages are generated from --help output, which is necessarily compact. What in particular do you think is missing, that will not be too lengthy for inclusion? The GNU project favors info pages over man pages, whether or not you choose to read them. I'm on Ubuntu Hardy, which lags a bit, but this is a standard problem against many GNU project tools. I'm running a number of .deb based systems including Etch, Lenny, Sid, Hardy, Intrepid, Jaunty and all have the same problem. The Bash and GCC manpages are long, but everything is there and searchable without having to resort to info. In particular, I was looking for the file type bits output in the -l option to ls(1), which should just be there in the manpage and not have to grovel through info(1) or find a project documentation web page. man(1) is a standard tool across many unixes. All the information should be there. Info(1) is a pet project of the GNU project. IMHO info(1) sucks. What's the justification for putting incomplete information in the manpages that's already available to another text tool on the same package? Even Perl has complete manpages for everything. Most directly, as other people have stated, the ls(1) manpage is incomplete because the standard for documentation in GNU is Info. GNU maintainers are directed to produce and maintain Info documentation for their software. There is a significant overhead in maintaining manpages too, and it requires a significant amount of effort to keep the two in sync (for a start because doing so is error-prone, necessitating regular careful checking). Why choose Info though? Essentially because it is navigable (i.e. hypertext) and flexible. It cannot have escaped your attention that almost every single manual page on any Unix-like system is fundamentally of a reference nature. Manpages containing significant amounts of tutorial and truly introductory material are very rare indeed. Info is much better for this kind of information; people can browse through the document to find the information they need and this does not much impede the use of the document for other purposes (for example reference or reading through worked examples). Info also has direct support for useful things like code examples, URLs, email addresses and so on. As a bonus it is easy to convert a Texinfo manual into a well-typeset book. It would certainly be possible to maintain manual pages and Info documentation in parallel, and keep it all up to date. Some GNU packages do this. GNU findutils, for example has both extensive manual pages and extensive Texinfo documentation. Is the find(1) manual page complete? No, there is a lot of information in the Texinfo documentation (notably security discussions, some reference information about -newermt, and worked examples) which is absent from the manpage. In fact, I dare say that if you proposed to complete the 70 or so manual pages for the coreutils programs and (importantly!) undertake to keep them up to date as the software is updated, for example by transferring changes the contributors make to the Texinfo source files, then the coreutils maintainer would probably work to incorporate your patches. What do you say? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Broken --inverse flag.
On Thu, Jul 9, 2009 at 12:09 PM, Daniel Kerstendkers...@gmail.com wrote: $ ps --inverse -- ERROR: Unknown gnu long option. [...] I would expect to receive a list of all processes currently not running I have implemented such an option, but I have not yet finished testing it. As soon as I have verified the correctness of each of the infinite number of not-running processes, I'll send a patch. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug found from ls command
On Wed, Jul 8, 2009 at 10:02 AM, James Youngmanj...@gnu.org wrote: [+bug-findutils] On Tue, Jul 7, 2009 at 5:36 PM, PGpgscoo...@gmail.com wrote: ah, great! thank you for the info. That helps me understand a lot. Now I see why find fails. And perhaps it's not worth the extra computation time required to, upon failure of cd'ing into the directory, trying to list it. It probably should, if it is readable. But I don't think any versions of GNU find will actually do this. OpenSolaris find doesn't either: flare:~/tmp$ find ft/tmp -ls 3474554 drwxr-xr-x 3 james1001 4096 Jul 8 09:54 ft/tmp 3474574 drw-r--r-- 2 james1001 4096 Jul 8 09:54 ft/tmp/nonexecutable find: cannot read dir ft/tmp/nonexecutable/: Permission denied flare:~/tmp$ ls -l ft/tmp/nonexecutable ft/tmp/nonexecutable/foo: Permission denied total 0 $ find ft -print ft ft/tmp ft/tmp/nonexecutable find: cannot read dir ft/tmp/nonexecutable/: Permission denied flare:~/tmp$ uname -a SunOS flare.spiral-arm.org 5.11 snv_101b i86pc i386 i86xpv James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug found from ls command
[+bug-findutils] On Tue, Jul 7, 2009 at 5:36 PM, PGpgscoo...@gmail.com wrote: ah, great! thank you for the info. That helps me understand a lot. Now I see why find fails. And perhaps it's not worth the extra computation time required to, upon failure of cd'ing into the directory, trying to list it. It probably should, if it is readable. But I don't think any versions of GNU find will actually do this. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: -0 option for tr
On Wed, Jul 1, 2009 at 11:47 AM, Craig Sandersc...@taz.net.au wrote: On Wed, Jul 01, 2009 at 10:13:15AM +0100, James Youngman wrote: The essential point though has already been made by Bob and Andreas; this causes failures for filenames which themselves contain newlines (all Unix-like filesystems I am familiar with allow this). i've already heard this stupid argument three times and it's as cretinous the fourth time as it was the first three. it's even more annoying to hear it again almost two days after i gave up the lost cause of getting anybody to actually give a damn about implementing a useful feature. but the really annoying thing about the argument is that it has nothing to do with my proposed feature. FILENAMES WITH NEWLINES ARE EXPLICITLY OUT OF THE FUCKING SCOPE OF THE REQUEST It's irrelevant whether you consider that case in scope or not, though. In the absence of external drivers (such as POSIX compatibility) the maintainers of the package (I don't maintain coreutils but I do maintain xargs) aren't going to implement a feature with a known design flaw - the fact that you personally don't care about the flaw is beside the point. SO HARPING ON ABOUT THEM NOT BEING CATERED TO IS CRIMINALLY FUCKING STUPID. is that in simple enough terms for you to understand? Of course I understand. The point is that you can't get rid of the edge cases (in this case, newlines in filenames) simply by wishing them away or saying I don't care. if you're too lazy or indifferent to implement a feature then have the guts to say so - as volunteers you have every right to say I don't want to do that - but don't make up lame bullshit excuses. But they're not excuses in that sense. You're facing a refusal to implement a bad idea. The refusal doesn't arise out of laziness. Where no file names contain newlines, the measure is not necessary anyway. actually, it is because the proposal wasn't about translating newlines in filenames. it was about changing the termination character from newline to null to make the input suitable for use with 'xargs -0' i would have thought it was obvious that newlines aren't the concern here, and never were. the point of using null terminated strings for input to xargs is to avoid problems with spaces and other punctuation characters. In that case use xargs -d not xargs -0. now fuck off and quit bothering me. i've wasted enough of my time on you losers. In these cases you might find it helpful to defer replying until the initial surge of anger on finding that other people don't agree with you has subsided. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: -0 option for tr
On Sun, Jun 28, 2009 at 2:20 AM, Craig Sandersc...@taz.net.au wrote: please add a -0 option to tr, which is equivalent to running: tr '\n' '\000' this is a useful command for converting \n-terminated input lines to null-terminated strings suitable for feeding into 'xargs -0' as many programs can not generate null-terminated ouput by themselves. This doesn't really buy you anything anyway. The reasons are discussed in the documentation for xargs and find. See for example info -f find -n Deleting Files info -f find -n Security Considerations for find info -f find -n Security Considerations for xargs The essential point though has already been made by Bob and Andreas; this causes failures for filenames which themselves contain newlines (all Unix-like filesystems I am familiar with allow this). Where no file names contain newlines, the measure is not necessary anyway. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Want to contribute to Open Source.
On Tue, Jun 30, 2009 at 2:08 PM, Philip Rowlandsp...@doc.ic.ac.uk wrote: On Tue, 30 Jun 2009, VIKAS wrote: Myself Vikas from India, i'm working as SQA in one of the big brand company. I want to contribute to open source by doing some work for GNU. Could you please guide me how can i contribute to GNU ? First, thank you for offering to help! Hi Vikas, This page is probably the best place to start: http://www.gnu.org/help/help.html Yes. There is also a more specific list at http://savannah.gnu.org/people/. That's a list of things that people need help with (some of the entries may be out of date, sorry). Of course, you will be the best judge of which tasks best fit your skills. I'd advise you to find something that offers a good fit to the things you enjoy working on, with a project whose code you use yourself. That is, work to improve programs you use yourself that are implemented with technologies you're familiar with. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort --key-debug
Sounds like a great idea to me. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
[ bug-coreutils moved to BCC, CC += bug-gnulib ] On Wed, May 27, 2009 at 8:04 PM, Giuseppe Scrivano gscriv...@gnu.org wrote: Hi Eric, Eric Blake e...@byu.net writes: Would it be worth starting to patch the testsuite to replace 'setuidgid -g list usr cmd arg' with 'chroot --user usr --groups=list / cmd arg' in order to give this feature more exposure and reduce our dependence on uninstalled apps? IMHO, since chroot now allows to specify users and groups by their names too, maybe it worths to move these functionalities in a gnulib module and share them with setuidgid. What all of you think? The locate program in findutils drops privileges, that fairly similar functionality might make a good gnulib module. Certainly it's the kind of thing one would hope to wirte and debug once, and reuse. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem
On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: 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 GB in size. Maybe the file is sparse? What does 'stat log_1848_1239927341.core' have to say? Chris already posted that in this thread. The file does appear to be sparse. However, the strace output also looks very unusual ... r...@localhost:/mnt/sys/external strace -v ls -l log_1848_1239927341.core svr4_syscall() = 0 syscall_6061(0x7fb817ec, 0x3995, 0x3995bf08, 0x3995c58c, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 syscall_6009(0, 0x1000, 0x3, 0x802, 0, 0x20, 0, 0x3996, 0, 0x3996, 0, 0x39964010, 0, 0x39936db0, 0, 0, 0x39948628, 0, 0, 0, 0, 0, 0, 0x2000, 0, 0x3995c288, 0, 0, 0, 0 , 0, 0x3995ca68) = 0x2aaa8000 svr4_fork() = -1 ERRNO_6002 (Unknown error 6002) svr4_fork() = -1 ERRNO_6002 (Unknown error 6002) [...] svr4_syscall() = -1 ERRNO_6001 (Unknown error 6001) -rwxrwxrwx 1 root root 109775240942714880 Apr 30 08:12 _1848_123 9927341.core svr4_evtrapret()= -1 ERRNO_6003 (Unknown error 6003) svr4_syscall() = 6011 svr4_syscall() = -1 ERRNO_6003 (Unknown error 6003) svr4_syscall() = -1 ERRNO_6205 (Unknown error 6205) Process 2697 detached ... which leads me to on the one hand wonder if the platform is MIPS, but on the other hand wonder if something else is going on, since the strace output seems to contain so many unknown errno values and the strace output doesn't seem to end with an exit syscall. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request: mktemp fifo
On Mon, May 18, 2009 at 1:15 PM, Stefan Behte s.be...@babiel.com wrote: Hi, and thanks for he fast reply. Surely it's possible that way, but that's two commands instead of just one. ;) Yes, combining tools with complementary features is the Unix way of doing things. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Error mounting Caixa Magica in Magalhes!
On Mon, May 11, 2009 at 12:08 AM, Rui Mauro Oliveira rui.olive...@tecep.net wrote: Good evening, Can i get help with this error o gives me in PC Magalhes whit Caixa Magica please: /dev/hda7: Multiply-claimed block(s) in inode 684772: 188998 188998 /dev/hda7: Multiply-claimed block(s) in inode 684811: 197181 197181 /dev/hda7: (There are 2 inodes containing multiply-claimed blocks.) /dev/hda7: File/var/log/daemons/info.log (inode #684772, mod time Wed Apr 29 19:56:47 2009) Has 2 multiply-claimed block(s), shared with 0 file(s): /dev/hda7: /dev/hda7: UNEXPECTED INCONSISTENCY; RUN fsck MANUALY. (i.e., without a or p options) Cordialmente Rui Oliveira Tecep - Optimus Negócios Rua Prof. Orlando Ribeiro, Nº6 Lj A 1600-796 Lisboa Telemovel: +351 932520201 Telefone: +351 212453287 Fax: +351 210127441 Email: rui.olive...@tecep.net http://www.tecep.net Recently there have been several people who have been asking about problems with GNU/Linux distributions on the GNU Coreutils mailing list, even though their problem is not actually with the Coreutils software. If you would be so kind could you tell us what has directed you to ask your question on this mailing list? We fear that there may be incorrect documentation pointing you here. If you would help us so that we could improve the directions it would help others. Thanks! You have reached the GNU Coreutils mailing list. The GNU Coreutils are the basic file, shell and text manipulation utilities of the GNU Operating System. You can learn more about GNU Coreutils here: http://www.gnu.org/software/coreutils/ The GNU Coreutils are part of the GNU Operating System. You can learn more about the GNU Project here: http://www.gnu.org/ But you are asking about Caixa Mágica applications. I am sorry but this is the wrong mailing list. We are unable to help you here. I hope that you will be able to find help in an appropriate place by reading the information printed in your magazine or by searching the web. (Your problem in particular seems to be with fsck -- the error message briefly describes what you need to do) Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add ability to print ACL's from ls
On Sat, May 9, 2009 at 11:59 AM, David Bartley dtbar...@csclub.uwaterloo.ca wrote: I considered this. There are at least 3 different variants of ACL's (POSIX, NFSv4 and MacOS X) and they are generally incompatible. UMich created patches to acl/libacl so that you could set NFS4 acl's via getfacl/setfacl using POSIX ACL syntax [1]. However, they recommend that you don't use them due to the formats not being fully compatible. Perhaps some kind of scheme-identifying prefix could help to solve this problem. However, that would probably make it harder to decide if two ACL representations in fact represent equivalent ACLs. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: test-memchr failure on rawhide
On Fri, May 8, 2009 at 11:21 PM, Bruno Haible br...@clisp.org wrote: Andreas Schwab wrote: They are free to access the object in any random order they like. The question is: How many bytes are the mem* functions free to access? How many bytes is the object large? If s is NULL, there _is_ no object. ISO C 99 7.21.5.1 says: The memchr function locates the first occurrence of c (converted to an unsigned char) in the initial n characters (each interpreted as unsigned char) of the object pointed to by s. NULL is not a pointer to an object. A program which passes NULL to memchr() has undefined behaviour. SIGSEGV is the lucky outcome here; the compiler is allowed to pour gasoline in your coffee instead of producing an executable if it likes. See section 3.4.3 of the standard. Returns The memchr function returns a pointer to the located character, or a null pointer if the character does not occur in the object. Can you give a justification why the function would be allowed to access more than n bytes? The question doesn't arise, though. You're talking about the range of reasonable behaviours applying in circumstances where the C standard imposes no requirements at all. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: New Feature Desired for tail
On Wed, May 6, 2009 at 11:15 PM, Brian McQueen mcqu...@yousendit.com wrote: The new feature is demonstrated by a wrapper script around tail which gives me the ability to use tail to drive arbitrary alerts like this (only the core concept lines are shown): # put it into the background tail -n 0 -f error_file working_file #wait for some lines to arrive while ! test -s working_file do echo nothing yet... Going to sleep for:timeout:$timeout: 2 sleep $timeout done #got some lines so cat them cat working_file This allows me to watch a file for maybe 10 second intervals, and grab all lines that arrived during that time interval. If nothing arrived, then it keeps on waiting. This effectively allows me to drive shell scripts with stdin model, but only on when new lines arrive. It is used like this: ./recent_line_tail error_log | alarm_handler_script This functionality could be put into tail with a single new option. Proposed Usage (a for alert, or maybe n for new?): tail -a 23 error_log I propose this would check for output each 23 seconds, and if it finds any it will cat it and stop. If there are no lines then it would wait another 23 seconds. Why not use something designed for the purpose of watching log files, for example http://www.fourmilab.ch/webtools/logtail/ but ... ? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: id confusion
On Wed, May 6, 2009 at 7:13 PM, Bauke Jan Douma bjdo...@xs4all.nl wrote: -r, --real print the real ID instead of the effective ID, with -ugG It's an abbreviated - perhaps too abbreviated form - of -u or -g or -G. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #10384] chroot feature request: --user and --group parameters
Follow-up Comment #4, bug #10384 (project coreutils): That's an option, certainly, and if the default is to remove supplementary groups, it's pretty safe. Another option is to call getgroups(), but then you need to decide whether to call it before chroot (when things like any necessary LDAP config files are around) or after the chroot (since perhaps the chroot environment contains a different /etc/groups file). In general this problem doesn't arise for people who do chroot /blah /bin/su - fred because while su picks up the group configuration somewhere in /blah, it's also linked against the libraries in /blah which presumably know how to handle it. Hence I think something like your suggestion is probably the best choice even though some users might prefer the groups to be selected automatically. I'm not sure about the user-interface choice of specifying group information in two places (the rhs of --userspec and also in --groups) but I can't think right now of a solution which is both sufficiently general and actually better. For example, saying --userspec=user:egid,group2,group3 seems initially reasonable but (a) doesn't allow the user to specify a configuration where the egid is not in the supplementary group list and (b) probably isn't supported by the parsing function you called. Therefore I think I'm voting for your --groups suggestion. ___ Reply to this item at: http://savannah.gnu.org/bugs/?10384 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot available: coreutils-7.2.66-428db1
On Thu, Apr 30, 2009 at 12:52 PM, Jim Meyering j...@meyering.net wrote:
James Youngman wrote:
make check fails in doc on a vanilla NetBSD5.0 system (released
yesterday) because no version of Perl is installed by default. In
fact make fails without explanation:
[...]
Thanks for reporting that, and especially for testing on a
just-released system!
The second change set below should fix that.
Rather than apply the patch I just downloaded your newer snapshot.
It's much clearer:
$ make check ; echo $?
[...]
/usr/bin/grep -E '\{.*\^[0-9][0-9]' ./*.texi exit 1 || :
/bin/ksh /home/james/tmp/cu/coreutils-7.2.69-269b/build-aux/missing
--run perl -e 1 /bin/ksh
/home/james/tmp/cu/coreutils-7.2.69-269b/build-aux/missing --run perl
-lne '/\...@var{/ or next; while (/\...@var{(.+?)}/g)
{ $v = $1;$v =~ /[A-Z]/
$v !~ /^\\/ and (print $ARGV:$.:$_), $m = 1 }
END {$m and (warn doc/Makefile: do not use upper case in
\...@var{...}\n), exit 1}' ./*.texi
/home/james/tmp/cu/coreutils-7.2.69-269b/build-aux/missing[108]: perl: not found
WARNING: `perl' is needed, and is missing on your system.
You might have modified some files without having the
proper tools for further handling them. Check the `README' file,
it often tells you about the needed prerequisites for installing
this package. You may also peek at any GNU archive site, in case
some other package would contain this missing `perl' program.
*** Error code 1
Stop.
make: stopped in /home/james/tmp/cu/coreutils-7.2.69-269b/doc
*** Error code 1
Stop.
make: stopped in /home/james/tmp/cu/coreutils-7.2.69-269b
*** Error code 1
Stop.
make: stopped in /home/james/tmp/cu/coreutils-7.2.69-269b
1
Thanks!
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot available: coreutils-7.2.66-428db1
make check fails in doc on a vanilla NetBSD5.0 system (released
yesterday) because no version of Perl is installed by default. In
fact make fails without explanation:
$ make check
*** Error code 1
Stop.
make: stopped in /home/james/tmp/cu/coreutils-7.2.66-428db1/doc
I guess this is because some failing command starts with @. Anyway,
re-running with make debugging turned on, we find that the problem is
that although configure determined that Perl was missing, it still
decides to run it:
$ make -d A check
[...]
*** Failed target: sc-lower-case-var
*** Failed command: /bin/ksh
/home/james/tmp/cu/coreutils-7.2.66-428db1/build-aux/missing --run
perl -e 1 2 /dev/null /bin/ksh
/home/james/tmp/cu/coreutils-7.2.66-428db1/build-aux/missing --run
perl -lne '/\...@var{/ or next; while (/\...@var{(.+?)}/g) { $v = $1; $v =~
/[A-Z]/ $v !~ /^\\/ and (print $ARGV:$.:$_), $m = 1 } END {$m and
(warn doc/Makefile: do not use upper case in \...@var{...}\n), exit 1}'
./*.texi
*** Error code 1
Stop.
make: stopped in /home/james/tmp/cu/coreutils-7.2.66-428db1/doc
Applying :@ to
Result of :@ is
I believe the cause is not that I changed a timestamp and hence forced
a generated file to be regenerated, but simply that make check will
fail without Perl:
doc/Makefile contains:
syntax_checks = \
sc-avoid-io \
sc-avoid-non-zero \
sc-avoid-timezone \
sc-avoid-zeroes \
sc-exponent-grouping \
sc-lower-case-var \
sc-use-small-caps-NUL
[...]
sc-lower-case-var:
@$(PERL) -e 1 2 /dev/null \
$(PERL) -lne $(find_upper_case_var) $(srcdir)/*.texi
From config.log:
configure:27190: checking for perl5.005 or newer
configure:27214: result: no
configure:27216: WARNING:
WARNING: You don't seem to have perl5.005 or newer installed, or you lack
a usable version of the Perl File::Compare module. As a result,
you may be unable to run a few tests or to regenerate certain
files if you modify the sources from which they are derived.
configure:27247: checking for sys/pstat.h
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Wishlist: --no-header option for df
On Mon, Apr 27, 2009 at 9:14 PM, Christian Hudon chr...@pianocktail.org wrote: Hello, I have a small feature request. It'd be nice to have a --no-header option to df that skips printing the header line. The feature is already implemented in sed:- $ df -P | sed -e 1d|head -3 /dev/mapper/mirror_a-root_fs 5160576 1045448 3852984 22% / tmpfs 1989896 0 1989896 0% /lib/init/rw udev 10240 280 9960 3% /dev The use case for this would be when doing stuff like (in a shell), to check the disk space on a particular partition on a long list of machines: for machine in `long list of machines` df --no-header /usr The output would be much easier to read without the all the interleaved header lines. Thanks for listening, Christian ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: list statistical properties for the list of files passed
On Thu, Apr 23, 2009 at 1:06 PM, George Marselis gmarse...@ebuyer.com wrote: Hey guys, thanks for all the hard work. I'm working as a sysadmin for a shop that specializes in Debian GNU/Linux. i got a directory with a couple of tens of milions of files. It's not such a great idea to do that. Far better to chop that up into at least 1000 subdirectories. But take care not to use more than about 32,000 subdirectories, as some Linux filesystems either don't allow it (ext3) or some operations become less efficient at that point (ext4's st_nlink changes meaning). I was trying to find the median access time of the files in that director and sort by percentiles. i got a little python script together, but i can't help thinking that this is a feature that will be needed in the future, with bigger filesystems. I'm not sure determine_median_access_time has such a big potential user base, to be honest. However, I'm not sure what your performance requirements are, but if performance is an issue, bear in mind that there are several partitioning algorithms that allow you to find the median of a dataset without fully sorting it. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] build: make --enable-silent-rules the default
On Thu, Apr 23, 2009 at 8:27 PM, Jim Meyering j...@meyering.net wrote: Automake has made it so a package maintainer has to go a little out of the way to make --enable-silent-rules the default. So I'm doing this: From 52c4018a9c1020c2250b4250dfdda1dfc1873284 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sun, 19 Apr 2009 13:41:52 +0200 Subject: [PATCH] build: make --enable-silent-rules the default * configure.ac (AM_INIT_AUTOMAKE): Remove silent-rules. Instead,... (AM_SILENT_RULES): Use this, with it's undocumented [yes] argument. Those who want verbose build output may configure with --disable-silent-rules or use make V=1. I think I would like to do something similar in findutils. It might make sense to add this guidance to Automake's canned INSTALL file too (findutils uses that unchanged and I have no interest in forking it). James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chroot documentation
On Tue, Apr 21, 2009 at 6:35 PM, Stefano Carucci stecaru...@hotmail.com wrote: Hello all! Can anyone suggest to me a detailed guide about the chroot implementation ? The implementation in coreutils or the one in your kernel?The implementation of chroot(1) in coreurils looks pretty much like this: chroot(the-specified-directory) chdir(/) execvp(your_program_name, argument_list); If that looks very short, well, it is. The coreutils implementation of chroot is only 115 lines, including header comment, option parsing, and error handling. What I am interested in is how it creates the new root, It doesn't. The directory to which you chroot must already exist. what the computational effort is Minimal. # /usr/bin/time -v chroot /var/vserver/chroot/debian/etch/x86/a /bin/true Command being timed: chroot /var/vserver/chroot/debian/etch/x86/a /bin/true User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 266% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 293 Voluntary context switches: 3 Involuntary context switches: 0 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 and what it does at a low-level; not just a synopsis. If you want to know what it does at a low level, you are better off enquiring into the properties of the implementation, not the command-line tool that thinly wraps the system call. You might want to download the sources for Linux or for some *BSD kernel or some such thing, in order to understand how the system call works. But this mailing list isn't really the right place to enquire about the internals of those kernels, since we don't write them. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp(1) fails to copy file from /proc
On Sun, Apr 19, 2009 at 1:52 PM, Jim Meyering j...@meyering.net wrote: Andreas Schwab wrote: Jim Meyering j...@meyering.net writes: Sure, but that's not the question. The question is whether we can assume short-read-on-regular-file implies EOF. I think you can look at it as if you are reading a growing file. Makes sense. But if a regular file is growing, then it's stat.st_size changes. For files in /proc, stat.st_size is always 0. If it is implemented that way, then it would be better to hide such counter-intuitive details from applications. Already, the fact that st_size is 0 for a known- and usually constant-sized, non-empty file is misleading -- probably contrary to POSIX, too, given the definition of st_size for a regular file. I wonder what would break if those types were changed from S_IFREG to S_IFIFO. One drawback might be that files in /proc are currently seekable. FIFO's aren't. It's a good thing that so few of the files in /proc are large enough to be affected. I guess this doesn't help solve the general problem of reading /proc files under arbitrary kernel versions, but I do find the standard of implementation of /proc files to be low. at least in some kernel versions; st_nlinks is also often wrong on directories, as well. I guess the problem sot st_size is that the code can't easily figure out how much data it will produce without actually generating it; maybe it would be efficient enough to make an overestimate (and perhaps pad the result with newlines). James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: options commande tail .
2009/4/16 bernard.si...@coopagri-bretagne.fr: Sur les serveurs Linux RedHat enterprise version 5 l'option +n ne fonctionne plus , il faut utiliser l'option -n +n a la place . Un positionnement de variable _POSIX2_VERSION a la valeur 199209 contourne ce probleme . Exemple de package : coreutils-5.97-19.el5 Please forgive me if I have misunderstood your message, but please try reading the FAQ : http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails Caracteristiques du serveur concerne [r...@calxc102 ~]# uname -a Linux calxc102 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Thanks for providing extra detail in your bug report, but it turns out that the kernel version is of no relevance to the processing of command-line options of tail. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug On CUT
On Thu, Apr 16, 2009 at 1:05 AM, Eric Blake e...@byu.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ar3s on 4/15/2009 5:25 PM: echo a|cut --delimiter= --fields=2- I have assumed that it would return an empty string but it returns a Is it normal or is it a bug in the matrix ? Not a bug. According to POSIX, when -f (--fields) is in effect, Lines with no field delimiters shall be passed through intact, unless -s is specified. http://www.opengroup.org/onlinepubs/9699919799/utilities/cut.html Indeed, the Texinfo documentation for cut also indicates this: -s, --only-delimited do not print lines not containing delimiters FWIW, I've used cut for years and years and didn't know about this feature. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp(1) fails to copy file from /proc
On Thu, Apr 16, 2009 at 1:54 PM, Jim Meyering j...@meyering.net wrote: Thank you for the bug report. The relevant code from coreutils/src/copy.c is here: /* A short read on a regular file means EOF. */ if (n_read != buf_size S_ISREG (src_open_sb.st_mode)) break; That optimization was added over three years ago, with this change: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25719a33154f0c6 It appears that it is not (no longer?) valid for most mainstream kernels, at least for files on /proc, so I'll remove it or adjust it. Really?This seems more like a kernel bug to me.Specifically, I was under the firm impression that a short read from a file _does_ mean that you've reached the end-of-file. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: faster fnmatch
[ CC += bug-findutils, bug-gnulib; bug-coreutils moved to BCC ] On Thu, Apr 16, 2009 at 8:09 PM, Ondrej Bilka nel...@seznam.cz wrote: Hello. I am writing partial fnmatch to speed up locate et al. Please note that locate is part of GNU findutils, not GNU coreutils. I have CC'ed this email to the correct list. Regular expression matching with locate -r is also faster than the default, globbing, match. Idea is save state state to match common prefix only once. fnmatch source is too complex so I wrote simplified version. My code is 2-4 times faster than fnmatch. Here is list what provided speedup and can be applied to original source FOLD causes worst performance slowdown. From what I tried is best convert in buffer to uppercase when needed. This seems like an attractive option but I'm a little concerned about whether this will produce the correct result with characters like ß or Ï and ï. Other optimalizations are based on preprocessing pattern 1. For each * we compute minimal size of rest and we have smaller for cycles. 2. We can replace *? by ?* 3. If * is followed by letter we check it at for cycle of * 4. If pattern contains four consecutive letters we compare them as int I'm, not certain I have fully understood your points, but if you can speed up gnulib's fnmatch implementation, that would be good news. I looked at preprocessing the glob pattern to convert it into a regular expression, but I think there were some problems around collating symbols and character equivalence classes (i.e. that it''s not possible for the application to extract information about these from the C library). Since I last looked at this issue though, Bruno has implemented a large amount of Unicode support in gnulib, and this may in fact help solve the problem too.I've CC'ed the message to bug-gnulib since that's where the folks who maintain the implementations of that library and the fnmatch replacement hang out. I also tried optimalizations which didnt worked. use mask to match four letters and ? strlen trick to find first letter after * faster. Boyer-moore skiping didnt work either. -- 50% of the manual is in .pdf readme files ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp(1) fails to copy file from /proc
On Fri, Apr 17, 2009 at 5:46 PM, Jim Meyering j...@meyering.net wrote: diff --git a/src/copy.c b/src/copy.c index 9b0e139..3cbeba4 100644 --- a/src/copy.c +++ b/src/copy.c @@ -699,10 +699,6 @@ copy_reg (char const *src_name, char const *dst_name, goto close_src_and_dst_desc; } last_write_made_hole = false; - - /* A short read on a regular file means EOF. */ - if (n_read != buf_size S_ISREG (src_open_sb.st_mode)) - break; } } The patch itself looks good, but it might be worth leaving in a comment indicating why the optimisation should not be reintroduced... James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #6797] shred option to use internal RNG
Follow-up Comment #5, patch #6797 (project coreutils): IMO both /dev/urandom and /dev/random should be used as sources of data for seeding PRNGs, as opposed to being used as sources of random data directly. My rationale for this is that even using /dev/urandom for large quantities of data will exhaust the system's entropy pool. ___ Reply to this item at: http://savannah.gnu.org/patch/?6797 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] sort: Add --threads option, which parallelizes internal sort.
On Fri, Apr 3, 2009 at 8:57 PM, Paul Eggert egg...@cs.ucla.edu wrote: More important, it's not clear to me what the role of the test suite ought to be. Should the test really fail if it doesn't get enough performance improvement with 2 threads? How do we decide what's enough? None of our other tests are performance tests so we are in a bit of a new ground here. I don't have a resolution to this puzzle, but I think we should probably try to avoid generating test failures on single-core machines (where, I assume, there is limited benefit from increasing the number of threads). While modern CPUs are generally multi-core, there is nothing to stop processes being bound to a subset of cores (or indeed, coreutils being built in a VM which is only allowed to use one core). James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bugs!
On Wed, Apr 1, 2009 at 1:41 AM, Henry Purvis golfer81...@yahoo.com wrote: Hi, um.my name is henry and there is a bug on an application I have (from cydia) and I typed in iPod --help on 'terminal' and it said to contact you guys to say that there was a bug.so could you please get it fixed? PLEASE! Could you let us know exactly what you typed and what the output was? The best thing would be to cut and paste all the text. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Indicate that you need Autoconf 2.61a-341 or newer to build current Automake.
On Wed, Mar 11, 2009 at 1:30 AM, Pádraig Brady p...@draigbrady.com wrote: James Youngman wrote: Signed-off-by: James Youngman j...@gnu.org --- README-prereq | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/README-prereq b/README-prereq index 91676f4..d7c9c36 100644 --- a/README-prereq +++ b/README-prereq @@ -27,5 +27,8 @@ getting the prerequisites for particular systems. $ cd automake ./configure --prefix=$HOME/coreutils/deps $ make install + 4. In order to build the current Automake code you will need + Autoconf 2.61a-341 or newer. + Isn't point 2 talking about autoconf? Are the versions listed in bootstrap.conf not sufficient? the bootstrap.conf file lists the dependencies of coreutils. The coreutils source will build with Autoconf 2.61, but you cannot built Automake from its source repository with that version of Autoconf. Building Automake from its source respository is necessary to get 1.10a, since that's not a release version. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in join: case comparisons don't work in multibyte locales
On Wed, Mar 11, 2009 at 11:57 AM, Bruno Haible br...@clisp.org wrote: OK, I'll work on the creation of a GNU project called 'libunistring', that will export the functions from gnulib as a shared library. My first reaction was, why isn't libunistring===glibc, but then we'd end up in a situation where gnulib would need to replace these functions on non-glibc systems anyway. I guess the documentation for such a library should explain quite carefully why developers should not just use ICU, though. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Indicate that you need Autoconf 2.61a-341 or newer to build current Automake.
Signed-off-by: James Youngman j...@gnu.org --- README-prereq |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/README-prereq b/README-prereq index 91676f4..d7c9c36 100644 --- a/README-prereq +++ b/README-prereq @@ -27,5 +27,8 @@ getting the prerequisites for particular systems. $ cd automake ./configure --prefix=$HOME/coreutils/deps $ make install + 4. In order to build the current Automake code you will need + Autoconf 2.61a-341 or newer. + Now we can build coreutils as described in README-hacking as long as $PATH starts with $HOME/coreutils/deps -- 1.5.6.5 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did I found a bug in ls?
On Sun, Mar 8, 2009 at 3:15 PM, Major Péter majorpe...@sch.bme.hu wrote: Hi! I would like to list some folders with they block-sizes, but only specific folders am I interested. So I would like to use find to list the correct folders for me: ls `find . -type d -user foo -name *` -name * is redundant I think. this is not working because ls can't find folders with spaces in there name, so I am using a pipe and sed, to make it comfortable: This is a very dangerous way to try to solve this problem. See the findutils Texinfo manual, in particular the section Safe File Name Handling. ls `find . -user major -type d -name * | sed 's,\ ,\\\ ,g'` If I'm using echo instead ls, the output is: ./foo\ bar So I tried to use: ls ./foo\ bar And it worked! The easiest way to check this is using this command in a folder where are folders with spaces in they names: ls `ls -a | sed 's,\ ,\\\ ,g'` Is there may an other way to find out the folders block-size belonging to a specific user? Do you mean the total size in blocks of the contents of each directory owned by a user?Or the size in blocks occupied by each directory (i.e. list of files) itself?I'm not sure I clearly understand what you wanted to do, so it is hard for me to be sure this is the correct answer, but this is a reasonable guess I think: $ find glpk -depth -type d -user youngman -print0 | du -s --files0-from=- 1936glpk/glpk-4.8/doc 12 glpk/glpk-4.8/examples/.deps 1756glpk/glpk-4.8/examples 356 glpk/glpk-4.8/include 176 glpk/glpk-4.8/src/.deps 3528glpk/glpk-4.8/src 8 glpk/glpk-4.8/sysdep/gnu 12 glpk/glpk-4.8/sysdep/w32 24 glpk/glpk-4.8/sysdep 7880glpk/glpk-4.8 960 glpk/tarfile 8844glpk Thanks for your help. Regards, Peter Major ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] build: allow ./bootstrap --srcdir=... to work with a git submodule
On Sat, Mar 7, 2009 at 5:19 PM, Jim Meyering j...@meyering.net wrote: When using git-bisect to see exactly when pr -oN broke, I was dismayed to see that I couldn't easily build some older versions from git due to their dependency on older versions of gnulib. Of course, this isn't at all surprising, once you think about it, and I've been remiss for not doing this sooner... So I'm about to make gnulib a git submodule of coreutils. FWIW, I approached this for findutils by recording the appropriate gnulib version in import-gnulib.config so that the correct version of gnulib is checked out during the bootstrap process. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: A request/suggestion for the behavior of chmod -X
On Sat, Mar 7, 2009 at 2:55 AM, Charles Jie ch...@keya.com.tw wrote:
Hi,
Situation:
I often need to pull lots of files from Windows boxes or from SD
cards in FAT filesystem filled with photos from digital camera.
The copied files usually have the x-bit enabled, which I hate very
much in Unix-like systems. With it, the colored 'ls' output is not
correct for any highlight like .zip .jpg .mp3 etc..
Problem:
chmod -x -R * is not useful because it clears the x-bit of
direcotries and forgets all files in sub-directories.
I checked the man page and hope chmod -X -R may help but
disappointed. chomd -X does the same thing as chomd -x.
Request:
I believe chmod -X should do something different from chomd -x
so that the -R can be rescued from its misfortune for the special
combination with -x.
This isn't really the Unix way of doing things. Instead of adding
every feature to every tool, there are instead a variety of tools that
can work together to build useful combinations. In this way one can
achieve things that just would not make sense as features of an
individual program. In your case you can use find. You might use
it like this for example:
find . -type f -exec chmod -x {} +
For further information, please read the info manuals for coreutils
and findutils:
info coreutils
info find
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in join command
On Wed, Feb 25, 2009 at 8:20 PM, Laurent Manchon lmanc...@univ-montp2.fr wrote: -- Hi, i have used a join command as: join -1 1 -2 1 -o 2.1,2.2,2.3,2.4,2.5,2.6,2.7,2.8,2.9 file.test V.test with the files i send you in attachment(files.zip). This command returns only 55 lines. The real number in the output must be 1031 lines. What's wrong ? Please try reducing your problem to the smallest possible pair of input files that reproduces the problem you're having. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Timezone handling in date command
On Thu, Feb 19, 2009 at 12:11 PM, Burba, Viktor viktor.bu...@siemens.com wrote: Dear guys, I have expierenced the following unexpeted behaviour by using the date command on SuSE SLES10(x86_64): I have timezone setup to Asia/Dubai (GMT+4), which has short name GST (Gulf Standart time) #date Thu Feb 20 20:00:00 GST 2009 #date --utc -d now Thu Feb 20 16:00:00 UTC 2009 - OK UTC+4 #date --utc -d Thu Feb 20 20:00:00 GST 2009 Thu Feb 20 10:00:00 UTC 2009 - ??? UTC+10 I think here some name problems with GST. Because there are four timezones with the same short name GST Guam Standart Time UTC+10 Gulf Standart Time UTC+4 Greenland Standart Time UTC-3 South Georgia Time UTC-2 Here looks like date uses UTC+10 for name GST, which is also timezone GST but Guam Standart time and not Gulf Standart time. How can I force date to use another time offset for GST name? It is probably better to use TZ=Asia/Dubai. See $ info coreutils Specifying time zone rules James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.12.208-2441 and strtold
On Wed, Jan 28, 2009 at 11:26 AM, Poor Yorick org.gnu.bug-coreut...@pooryorick.com wrote: Couldn't check out coreutils at work because corporate firewall blocked everything but http access, which always hung during git-clone. Perhaps if you try a shallow clone by using git clone --depth 2 or similar, this may work around the problem. Or not, it depends on what causes the hang. Finally got a copy of the repository at home, but no mention of 6.12-213-gcfe3602 in logs or tags. This is a very good question. SImply put, 6.12-213-gcfe3602 is whatever version of coreutils causes ./build-aux/git-version-gen to print that string.So here I have $ ./build-aux/git-version-gen .version ; echo 6.12.7-86535-dirty If I want 6.12-213-gcfe3602 then I need to somehow know that the final part of the string 6.12-213-gcfe3602 is an abbreviated version number.I don't know where a person should ideally go to figure this out, if they don't know that build-aux/git-version-gen exists. One answer is that the configure.ac file normally contains the package version number, and in the case of coreutils, this says: # Make inter-release version strings look like, e.g., v6.9-219-g58ddd, which # indicates that it is built from the 219th delta (in _some_ repository) # following the v6.9 tag, and that 58ddd is a prefix of the commit SHA1. AC_INIT([GNU coreutils], m4_esyscmd([build-aux/git-version-gen .tarball-version]), [bug-coreut...@gnu.org]) $ git checkout gcfe3602 error: pathspec 'gcfe3602' did not match any file(s) known to git. Of course. g isn't a hex digit, I cut-and-pasted too much. Try again without it.. $ git checkout cfe3602 HEAD is now at cfe3602... seq: solve e13188e7ef7bbd609c1586332a335b4194b881aa more cleanly Aha, that seems satisfactory.Of course if you specify too small a value for --depth in your clone command, the revision you are looking for may not be in your local repository - you can deepen your local repository with git fetch --depth. Basically, my goal is to find the most bug-fixed version of the 6.12 series. Perhaps what I really want is the v6.12 tag in git (git newbie here)? But I'm curious how these various snapshots can be identified and found. Help? I hope this helped a bit. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Update James Youngman's email address
On Sun, Feb 22, 2009 at 12:41 AM, James Youngman j...@gnu.org wrote: * THANKS: Update James Youngman's email address -James Youngman james+use...@free-lunch.demon.co.uk +James Youngman j...@gnu.org I haven't used that email address at all since about 2000, and I'm guessing that whatever that contribution was, it was probably between about 1994 and 1997.The edit in git (4c1158ba) relates to the merge into coreutils, do we have any archived repositories of the ancestral projects? I have no recollection at all of making a contribution back then (thought the address is of course mine). James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date overflow in year 2038
On Sat, Feb 14, 2009 at 3:45 AM, David M. Dowdle ddow...@clouded.leopard.net wrote: I'd rank this as low priority, but people doing things like 30 year mortages will be hitting this already. Mortgage calculations probably shouldn't be using time_t anyway; use of time_t for future calculations assumes that we already know how long each year is going to be, to the nearest second[1].Mortgage agreements on the other hand specify dates in civil time and therefore the duration of the agreement in seconds can't be precisely known when the agreement is signed. For example were I to take out a mortgage that starts in December but ends on 1st April 2039, the actual length of the mortgage (as putatively measured by using time_t) would depend both on the leap seconds occurring between now and then and also the summer-time regulations in effect in 2039, which nobody has any way of predicting right now. James. [1] ... or that the precise alignment between future values of time_t and calendar time doesn't matter much ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Providing pointers to more generic help
Having inhabited a number of GNU mailing lists for few years now, I see that people occasionally email them with wholly unrelated problems. My current guess is that this happens because they happen to see --help output from a GNU program or see the BUGS section of some GNU manpage, and decide to ask that email address for help with their problem. There was a recent mail to bug-coreutils in which somebody asked for help with an installation CD on bug-coreutils@gnu.org, for example. I can see how they got to that point, quite reasonably (via man install or install --help). But we weren't able to help them. We're working on clearer text to indicate what install is for, but I realised this morning that we have an opportunity to help in a more general way. Often a person seeking to solve a problem doesn't yet know what tool they need to use to solve (or even diagnose) their problem. This of course is one of the problems with man pages that Info tries to solve. However, I think there is probably a case to be made for putting a very generic link on how to get help with free software in GNU manpages, --help output and so forth. The logical thing to do is put a single web page somewhere on www.gnu.org and include in that page things that help users find resources to help them. I've made an outline of such a document below. It would likely be an enhancement to the document currently at http://www.gnu.org/help/gethelp.html. What do you think? If you think this is a good idea but think the outline could be better, please et me know. Thanks, James. !--#include virtual=/server/header.html -- TITLEGetting Help With Free Software - GNU Project - Free Software Foundation (FSF)/TITLE LINK REV=made HREF=mailto:webmast...@www.gnu.org; META NAME=keywords CONTENT=GNU, help, support, free software meta http-equiv=Description content=How to get help with Free Software / BASE HREF=http://www.gnu.org/; !--#include virtual=/server/banner.html -- H2Getting Help With Free Software/H2 !-- Maybe include a brief pointer to the 'this document in other languages' footer. -- !-- Brief description of what this document is for. Essentially, the purpose of this document is to be a useful thing for the BUGS section of GNU manpages to point to, to help those who have not identified a bug, but simply need more (or a different form of) help. An illustrative example is people who are looking at the manpage for install because they want to install a binary package. -- H3Support-related Benefits of Free Software/H3 !-- How the three freedoms help people to help you. -- !-- The fact that anybody can fix it probably means they already did that. -- !-- I don't think this document is the right place to rant about how unuseful it is to rule out Free Software just because of the lack of warranty. This document is intended to be a resource more than a manifesto. We already have a manifesto. -- H3Helpful Resources Provided by the GNU Project/H3 !-- Texinfo documentation, web pages, mailing lists. -- H3Accessing GNU Documentation/H3 H4Info documentation/H4 H4Web pages/H4 H3Other Documentation/H3 H4The Linux Documentation Project/H4 H4Usenet and Web FAQs/H4 !-- Usenet FAQs in terms of origin; I am not sure that seeking help on Usenet would be useful these days, except for a small set of groups. -- H3Help With Specific Distributions/H3 !-- If you're running a GNU/Linux distribution, there are plenty of help resources specific to the one you're using. Explain how to find these. -- H3Mailing Lists and Newsgroups/H3 H4How to Find the Right Mailing ListH4 !-- Point to the GNU mailman instance. Also GMANE and other similar mailing list archives. -- H4How to Describe Your ProblemH4 !-- Remind people to check that they're using an up-to-date version. Don't make this an H3 heading, because the reader may not know (yet) how to do such a thing, and we want them to read this document, not be scared off. -- H4Getting Help in Your LanguageH4 H3Real-Time Help from People/H3 H4Real-Time Help over the Internet/H4 !-- I plan to mainly give pointers to IRC networks/channels. Is anything else real-time and useful? -- H4Meeting People Who Can Help/H4 !-- LUGs etc. Do we call them GNU/LUGs? :) -- H3Your Option to Pay for Support/H3 !-- Explain that you can get _anybody_ to help, on any basis agreeable to both parties. -- !-- Pointer to the GNU Service Directory. -- /div!-- for id=content, starts in the include above -- !--#include virtual=/server/footer.html -- div id=footer P Return to A HREF=/home.htmlGNU's home page/A. P Please send FSF amp; GNU inquiries amp; questions to A HREF=mailto:g...@gnu.org;EMg...@gnu.org/EM/A. There are also A HREF=http://www.fsf.org/about/contact.html;other ways to contact/A the FSF. P Please send comments on these
Re: Direct-hit help on specific commands with Info
[ bug-coreutils moved to BCC ] On Sat, Dec 20, 2008 at 11:31 AM, Andreas Schwab sch...@suse.de wrote: Looks like your info system is misconfigured. The coreutils info file has a direntry section that lists all invdividual utilities as menu entries that redirect to the respective invocation nodes in the coreutils info file. This direntry section is supposed to be copied (by install-info) to the info dir file on installation. You're right. Thanks for the pointer. This looks like http://bugs.debian.org/139569 - which has been open for six years now. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] getopt: Indicate the problem with ambiguous options clearly.
---
ChangeLog|6 ++
lib/getopt.c | 25 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7faac2b..b593588 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-12-14 James Youngman j...@gnu.org
+
+ getopt: Indicate the problem with ambiguous options clearly.
+ * lib/getopt.c (_getopt_internal_r): Print the first and second
+ possibility when there is an ambiguous match.
+
2008-12-14 Bruno Haible br...@clisp.org
Update doc for POSIX:2008.
diff --git a/lib/getopt.c b/lib/getopt.c
index f1e6d1f..107538f 100644
--- a/lib/getopt.c
+++ b/lib/getopt.c
@@ -480,8 +480,8 @@ _getopt_internal_r (int argc, char **argv, const char
*optstring,
char *nameend;
const struct option *p;
const struct option *pfound = NULL;
+ const struct option *pambig = NULL;
int exact = 0;
- int ambig = 0;
int indfound = -1;
int option_index;
@@ -512,19 +512,25 @@ _getopt_internal_r (int argc, char **argv, const char
*optstring,
|| pfound-has_arg != p-has_arg
|| pfound-flag != p-flag
|| pfound-val != p-val)
- /* Second or later nonexact match found. */
- ambig = 1;
+ {
+ /* Second or later nonexact match found. We remember
+ it instead of breaking out of the loop in case
+ there is a later exact match to be found. */
+ pambig = p;
+ }
}
- if (ambig !exact)
+ if (pambig !exact)
{
if (print_errors)
{
#if defined _LIBC defined USE_IN_LIBIO
char *buf;
- if (__asprintf (buf, _(%s: option `%s' is ambiguous\n),
- argv[0], argv[d-optind]) = 0)
+ if (__asprintf (buf, _(%s: option `%s' is ambiguous,
+ since for example it might mean --%s or
--%s\n),
+ argv[0], argv[d-optind],
+ pfound-name, pambig-name) = 0)
{
_IO_flockfile (stderr);
@@ -539,8 +545,11 @@ _getopt_internal_r (int argc, char **argv, const char
*optstring,
free (buf);
}
#else
- fprintf (stderr, _(%s: option `%s' is ambiguous\n),
- argv[0], argv[d-optind]);
+ fprintf (stderr, _(%s: option `%s' is ambiguous,
+since for example it might mean --%s or
--%s\n),
+ argv[0], argv[d-optind],
+ pfound-name, pambig-name);
+
#endif
}
d-__nextchar += strlen (d-__nextchar);
--
1.5.6.5
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] getopt: Indicate the problem with ambiguous options clearly.
On Sun, Dec 14, 2008 at 7:05 PM, Bruno Haible br...@clisp.org wrote: James Youngman wrote: +2008-12-14 James Youngman j...@gnu.org + + getopt: Indicate the problem with ambiguous options clearly. + * lib/getopt.c (_getopt_internal_r): Print the first and second + possibility when there is an ambiguous match. The patch looks good. But the master sources of the 'getopt' module are in glibc, Have you tried submitting your patch as a glibc bug in http://sourceware.org/bugzilla/? (Patches sent to the libc-alpha mailing list sometimes get forgotten; submission through bugzilla is more reliable.) Thanks for the tip, I've added http://sourceware.org/bugzilla/show_bug.cgi?id=7101 James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date(1): -d argument parsing error
On Wed, Dec 10, 2008 at 1:08 AM, Jan Minář [EMAIL PROTECTED] wrote:
2008/12/10 James Youngman [EMAIL PROTECTED]:
$ date -d next `LC_ALL=C date +%A`
mercredi 10 décembre 2008, 00:00:00 (UTC+)
^^^
You've just demonstrated that the bug is present in the French
localization as well -- the you got is *today*, not *next* Wednesday,
as it should be.
Now I see what you mean. The effect appears to be caused by this
piece of code in gnulib's getdate.y:
if (pc.days_seen ! pc.dates_seen)
{
tm.tm_mday += ((pc.day_number - tm.tm_wday + 7) % 7
+ 7 * (pc.day_ordinal - (0 pc.day_ordinal)));
tm.tm_isdst = -1;
Start = mktime (tm);
if (Start == (time_t) -1)
goto fail;
}
Certainly on the basis of the documentation (getdate.texi lines
331-337 and 389-398), this would appear to be a bug:-
@findex next @var{day}
@findex last @var{day}
A number may precede a day of the week item to move forward
supplementary weeks. It is best used in expression like @samp{third
monday}. In this context, @samp{last @var{day}} or @samp{next
@var{day}} is also acceptable; they move one week before or after
the day that @var{day} by itself would represent
...
@findex now @r{in date strings}
@findex today @r{in date strings}
@findex this @r{in date strings}
The strings @samp{now} or @samp{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
items, like in @samp{12:00 today}. The string @samp{this} also has
the meaning of a zero-valued time displacement, but is preferred in
date strings like @samp{this thursday}.
Specifically, my take on this is that next is clearly intended to
move the date forward, and had the user wanted a movement of zero days
when today is the indicated weekday, they had the option of specifying
'this Wednesday' instead of 'next Wednesday'.
I'm normally reluctant to accept the need to change getdate.y (though
this is not my call anyway of course, I'm not a maintainer) because of
the fact that it's been around a long time and somebody somewhere may
be relying on the current behaviour. However, I also note that the
next weekday-name is not currently tested by gnulib's
tests/test-getdate.c program, and so it looks to me as if the weight
of evidence favours changing this. The difficulty of course is in not
breaking something else.
I've added [EMAIL PROTECTED] to the CC list. That's the place to
send your patch to fix the bug. The gnulib README file describes how
to contribute. For other information about gnulib, including
directions for accessing the GIT source repository, please see
http://savannah.gnu.org/projects/gnulib.
Thanks,
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date(1): -d argument parsing error
On Tue, Dec 9, 2008 at 5:19 PM, Jan Minář [EMAIL PROTECTED] wrote: Hi. date(1) command parses next $day_of_week_today (where $day_of_week_today is today's day name) incorrectly: $ date Tue Dec 9 17:16:50 GMT 2008 $ date -d next `date +%A` Tue Dec 9 00:00:00 GMT 2008 It should print the next Tuesday's date, i.e. today + 7 days. The date parser does not support as input weekday names in arbitrary languages; see the documentation for the date command. Fortunately, the problem is simple to work around, by overriding the locale selection for the inner date command:- $ date -d next `LC_ALL=C date +%A` mercredi 10 décembre 2008, 00:00:00 (UTC+) James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #24949] coreutils pwd not implementing latest POSIX features
On Mon, Dec 1, 2008 at 2:04 AM, Paul D. Smith [EMAIL PROTECTED] wrote: Follow-up Comment #2, bug #24949 (project coreutils): The problem is that without -P I can't invoke pwd from things like Perl portably. If I use my $pwd = `pwd`; and it runs a shell and uses the shell builtin version of pwd, then I get the wrong thing (I explicitly want the real path; what POSIX defines pwd -P to return). But on the other hand, if I use my $pwd = `pwd -P`;, which is what a correct POSIX-conforming script would do, and it runs coreutils pwd instead of a shell builtin, I get a syntax error. If you can rely enough on the platform being POSIX-conforming for -P to work, then why not just use Perl's POSIX module? It seems to me that that would be more portable still. ~$ cat pwd.pl #! /usr/bin/perl use POSIX qw(getcwd); print 1: . POSIX::getcwd() . \n; my $pwd = `pwd`; chop($pwd); print 2: . $pwd . \n; my $pwd = `pwd -P 2/dev/null || pwd`; chop($pwd); print 3: . $pwd . \n; ~$ perl pwd.pl 1: /home/james 2: /home/james 3: /home/james James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command option -x, --one-file-system
On Fri, Nov 28, 2008 at 12:51 PM, ebloch [EMAIL PROTECTED] wrote: cp command option : -x, --one-file-system stay on this file system sometimes does not stay on the same filesystem. using cmd line : cp -r -u -p -x -f -v --target-directory='/abc/def/123/456/xx /home or cp -rupxfv --target-directory='/abc/def/123/456/xx /home where '/home' is mounted on a different volume than '/'. Detected by a call from python with os.popen(). Your bug report is a little short of explanation. What source files from / get copied to /abc/...? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] pwd: add pwd -P, -L to TODO
* TODO: Add to-do entry for -P and -L options of pwd. --- TODO |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index f38c0b6..0dbb85f 100644 --- a/TODO +++ b/TODO @@ -36,6 +36,11 @@ printf: platforms where the native *printf(3) is deficient. Suggestion from Eric Blake. +pwd: + Implement the options -P and -L in a POSIX-compatible way. + Note the instructions in the initial paragraph of this file + before starting. + renice: POSIX utility, needs implementing. suggestion from Karl Berry (among others). Bob Proulx is working on this. -- 1.5.6.5 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
[ CC ++ [EMAIL PROTECTED] ] On Tue, Nov 11, 2008 at 2:58 PM, Andrew McGill [EMAIL PROTECTED] wrote: What would you expect this to do --: find -type f -print0 | xargs -0 -n 8 --max-procs=16 md5sum ~/md5sums Produce a race condition :)It generates 16 parallel processes, each writing to the md5sums file. Unfortunately sometimes the writes occur at the same offset in the output file. To illustrate: ~$ strace -f -e open,fork,execve sh -c echo hello foo execve(/bin/sh, [sh, -c, echo hello foo], [/* 39 vars */]) = 0 [...] open(foo, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 ~$ strace -f -e open,fork,execve sh -c echo hello foo execve(/bin/sh, [sh, -c, echo hello foo], [/* 39 vars */]) = 0 [...] open(foo, O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 This version should be race-free: find -type f -print0 | xargs -0 -n 8 --max-procs=16 md5sum ~/md5sums 21 I think that writing into a pipe should be OK, since pipes are non-seekable. However, with pipes in this situation you still have a problem if processes try to write more than PIPE_BUF bytes. Is there a correct way to do md5sums in parallel without having a shared output buffer which eats output (I presume) -- or is losing output when haphazardly combining output streams actually strange and unusual? I hope the solution about solved your problem - and please follow up if so. This example is probably worthy of being mentioned in the xargs documentation, too. Thanks for your comment! James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 294348] Re: ubuntu directing users to coreutils mailing list for general problems
On Sun, Nov 9, 2008 at 7:57 AM, Jim Meyering [EMAIL PROTECTED] wrote: James Youngman [EMAIL PROTECTED] wrote: Perhaps something like the attached patch to the usage message might be worthwhile (though I think it is probably too wordy). Thank you. I agree. How about this? I like that, thanks. +This install program copies files (often just compiled) into destination\n\ +locations you choose. If you want to download and install a ready-to-use\n\ +package on a GNU/Linux system, you should be using a package manager\n\ +like yum(1) or apt-get(1).\n\ Maybe we could squeeze instead into that sentence, either at the end or just before be using? Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
On Sun, Nov 9, 2008 at 11:06 PM, Dr. David Alan Gilbert [EMAIL PROTECTED] wrote: I keep wondering if the OS level needs a better interface; an 'openv' or 'statv' or I'm currently wondering if a combined call would work - something which would stat a path, if it's a normal file, open it, read upto a buffers worth and if finished close it - it might work nicely for small files. I suspect that a combined call would not be widely useful, though it would likely provide a useful speedup for your use case. I suspect that the statv/openv combination would fit more use-cases. A statv function could be useful for anything that uses fts for example (rm, find, ...) and for file-open dialogue boxes. I have to say though that I've never used writev. However, people continue to design more advanced filesystems; the filesystem knows a lot about how the data is arranged and (therefore) the optimal order in which to perform operations. The application knows a lot about the set of operations it plans to execute, too. However, these two pieces of software communicate through a small keyhole; the POSIX file API. I'm not clear though on what nature of API might be more generally useful for a wide class of programs; existing programs after all are designed in ways that work well with the existing operating system interfaces. Perhaps this overcomplicates the issue though, since not many programs interact with more than a few dozen files and therefore probably wouldn't need to adopt a more complex API. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: ls: add --user-format option for user defined format
On Fri, Nov 7, 2008 at 8:39 AM, Jim Meyering [EMAIL PROTECTED] wrote:
Have you considered adding SELinux-related format directives to GNU find?
I would likely accept such patches into find, subject to a GNU
copyright assignment of course.
More generally, a more flexible syntax for find's -printf formats
might be useful. Because of the limited number of format directive
letters remaining unused in find, I have been thinking about
directives based on names. This might look like %20.18{pathname}s,
%{filemode}o %{filemode}d and so on. It's inappropriate to
complicate the format directives completely to the point where find
has an embedded string formatting language though (as well as its
embedded filesystem predicate language). If somebody did this work it
would probably make sense to refactor the code a bit such that the
formatting implementation could be lifted out as a module and re-used
elsewhere.
If you're interested in pursuing this (either the SELinux format
enhancements or the more ambitious change), please email
[EMAIL PROTECTED]
Thanks.
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
On Sat, Nov 8, 2008 at 6:05 PM, Jim Meyering [EMAIL PROTECTED] wrote: How about parallelizing it via xargs, e.g., $ echo a b c d e f g h | xargs -t -n4 --no-run-if-empty \ --max-procs=2 -- cp --target-directory=dest cp --target-directory=dest a b c d cp --target-directory=dest e f g h For tools lacking a --target-directory option there is this shell trick: $ echo a b c d e f g h | xargs -n4 --no-run-if-empty --max-procs=2 -- sh -c 'prog $@ destination' prog James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 294348] Re: ubuntu directing users to coreutils mailing list for general problems
Perhaps something like the attached patch to the usage message might be worthwhile (though I think it is probably too wordy). James. From 54614d88bc91d0c188108b467fb518c7d3de7c06 Mon Sep 17 00:00:00 2001 From: James Youngman [EMAIL PROTECTED] Date: Sat, 8 Nov 2008 21:55:50 + Subject: [PATCH] install: indicate clearly it's not for installing packages. To: bug-coreutils@gnu.org * src/instrall.c (usage): Indicate the program copies binary files, as opposed to installing packages. --- src/install.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/install.c b/src/install.c index a7c3b3d..a320868 100644 --- a/src/install.c +++ b/src/install.c @@ -816,6 +816,14 @@ Usage: %s [OPTION]... [-T] SOURCE DEST\n\ ), program_name, program_name, program_name, program_name); fputs (_(\ +\n\ +The install utility copies files (which you will normally have recently\n\ +compiled) into the location you decided to install them. If in fact you\n\ +want to download and install a ready-to-use package instead of compiling it\n\ +yourself, you should probably be using different program. The right choice\n\ +of program depends on your operating system. Popular choices for GNU/Linux\n\ +systems are yum(1) and apt-get(1).\n\ +\n\ In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to\n\ the existing DIRECTORY, while setting permission modes and owner/group.\n\ In the 4th form, create all components of the given DIRECTORY(ies).\n\ -- 1.5.6.5 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add option processing tests for 'expr'
On Wed, Oct 15, 2008 at 7:46 AM, Jim Meyering [EMAIL PROTECTED] wrote: Pádraig Brady [EMAIL PROTECTED] wrote: The attached tests pass with both your and Paul's patches. Thanks everybody for doing that. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Shred and symbolic links. People use it like a safer rm and get...
Interesting points, thanks! Since shred cannot do anything useful with a symbolic link there are only two (no, three) possible courses of action: 1. Dereference the link; shred the thing it points to. 2. Unlink the symbolic link 3. Refuse to do anything At the moment then, shred does (1). shred -u shreds the file and then truncates it. The -f option is not needed. I think option (2) is inconsistent with the other things that shred does; it scrambles things but (by default) doesn't delete them. The principle of operation of shred(1) is that it is not reversible. I always look extra carefully at stuff I'm putting in the shredder, to make sure that really nobody needs it.It might be reasonable to require shred to refuse to do anything with a symbolic link unless the -f option is given. The rationale for this would essentially be that the cost of a mistake on the part of the user is huge, and (so the argument would go) this potentially changes the balance between trust the user and protect the user. (Being Unix-y, coreutils goes in mainly for trust the user). So interpreting your point a bit freely, I guess you'd prefer this: shred symlink: yields an error message; nothing is done shred -u symlink: likewise shred -f symlink: shreds the file the symlink points to shred -u -f symlink: shreds the file the symlink points to, truncates the file, but leaves the symlink alone (this is the current behaviour we see without options) This change is not by any means obvious; for example, it removes the current protection that you get in this case: ~/tmp$ rm -f foo bar ~/tmp$ echo hello foo ~/tmp$ ln -s foo bar ~/tmp$ chmod 400 foo ~/tmp$ ls -l foo bar lrwxrwxrwx 1 james james 3 2008-09-20 15:25 bar - foo -r 1 james james 6 2008-09-20 15:25 foo ~/tmp$ shred bar shred: bar: failed to open for writing: Permission denied ... if we are using -f to tell shred to follow the symbolic link, there is no extra option needed for yes, really shred a read-only file. Personally, I think that the loss of this last protection is worse than the protective effect of not following symbolic links by default. So if these are the only possible options, I would prefer to leave things as they are. An alternative would be to add -P and -L options, but the current default is like -L, so this change also would not be without problems. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: About win-bash customized environment
On Sat, Sep 20, 2008 at 12:08 PM, Softeam [EMAIL PROTECTED] wrote: Hello from Paris, Since I downloaded and watched the Revolution OS documentary yesterday I have decided to install win-bash on my computer. I noticed that win-bash doesn't read .bash_profile, .profile, etc. customization files from the working directory at login - forcing me to source them at each login. Am I doing something wrong ? This is the GNU coreutils mailng list. Coreutils does not include the Bash shell, so we're not in much of a position to help with your problem (that is, it's not our software you are using). You could try asking for help on a Bash-related mailing list, but then on the other hand your problem looks Windows-specific. I think you might have better luck asking for help from the win-bash folks. Fortunately, their homepage includes a link to the bug-reporting address: http://win-bash.sourceforge.net/ (I found this with a very simple web search). Stepping back for a second though, the great thing about the Unix shell (and Bash as an example of it) is that it's easy to plug lots of powerful tools together. If you only have Bash installed on your system, all those great tools are missing. While you can still do useful things with Bash in such an environment, it's quite limiting. I suggest that you might find it useful to have all those other tools, too. A great way to do this would be to use GNU/Linux. But this is not always feasible (perhaps you have just one computer which needs to run Windows and cannot run any kind of virtual machine). A great alternative for this situation is Cygwin, which is a full environment of Unix-like tools that runs on various versions of Windows. For more information, please see http://www.cygwin.com/. As an added bonus, you will see that Cygwin includes a much more recent version of the Bash shell. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug of sort??
It looks to me like you probably just have locate settings that you don't like:- ~$ sort -t -k 1Desktop/T 20th Century Fox Animation /guid/9202a8c04000641f80923a5a 20th Century Fox/guid/9202a8c04000641f80136722 20th Century Fox Television /guid/9202a8c04000641f80d38838 Acer Computer Australia /guid/9202a8c04000641f80876087 Acer/guid/9202a8c04000641f8021b67f Acergy /guid/9202a8c04000641f80f082b3 Acer India /guid/9202a8c04000641f80875b5c Acerinox/guid/9202a8c04000641f80ddcbc9 Acer Laboratories Incorporated /guid/9202a8c04000641f80c9f469 ~$ LC_ALL=C sort -t -k 1Desktop/T 20th Century Fox/guid/9202a8c04000641f80136722 20th Century Fox Animation /guid/9202a8c04000641f80923a5a 20th Century Fox Television /guid/9202a8c04000641f80d38838 Acer/guid/9202a8c04000641f8021b67f Acer Computer Australia /guid/9202a8c04000641f80876087 Acer India /guid/9202a8c04000641f80875b5c Acer Laboratories Incorporated /guid/9202a8c04000641f80c9f469 Acergy /guid/9202a8c04000641f80f082b3 Acerinox/guid/9202a8c04000641f80ddcbc9 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uniq works not correct
On Wed, Sep 10, 2008 at 9:51 AM, Pádraig Brady [EMAIL PROTECTED] wrote: Same error happens on fedora. So it's probably related to that horrible i18n patch applied by distros [...] Could be. Debian Lenny is unaffected. $ sort test test | uniq -u | wc -l ; wc -l test 0 45 test ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in date?
On Tue, Sep 9, 2008 at 1:47 PM, Enrique Arizón Benito [EMAIL PROTECTED] wrote: Upps, I forgot it. #date -s 1970-01-01 00:00:01 date: cannot set date: Invalid argument It looks like date is simply reporting an error that it received from the operating system. The strace utility (or some platform-specific replacement if you are not using Linux) should be able to confirm this. Thu Jan 1 00:00:01 CET 1970 Curiosly after the Invalid argument error, date properly prints the new hour but doesn't change it. This is almost certainly because the date program understands the date you refer to, but failed in its attempt to set the system clock to that value. That's what makes me think it's really a bug. More likely it's because CET is 1h ahead of UTC and therefore the time you specified is before the Epoch.But Eric already said that, so perhaps you ruled out that possibility but did not say so. James ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: sort by human-readable disk sizes
On Tue, Sep 25, 2007 at 5:46 PM, Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Mart, let me know if you can assign copyright to the FSF, and I'll send you the paperwork. Paul? Thanks, Mart. Nobody has come up with a better solution, so let's go with Mart's, with one proviso: it should be documented a bit more conservatively, in that the documentation shouldn't promise any particular behavior for unnormalized numbers. How about putting something like this in the documentation, instead of the last paragraph of what was proposed in http://article.gmane.org/gmane.comp.gnu.coreutils.bugs/6793? Did this ever move forward? Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
On Tue, Sep 2, 2008 at 12:06 PM, Jim Meyering [EMAIL PROTECTED] wrote:
Andreas Schwab [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Kamil Dudka [EMAIL PROTECTED] wrote:
+#define LOG_EQ(a,b) (((a)(b))||(!(a)!(b)))
This can be written more simply as !((a) ^ (b))
Only if the operands are already boolean, and then you can just use a == b.
Oh. Right. To be general, it'd have to be like this,
but this is probably too obtuse unless you're comfortable
with the !! pseudo operator idiom:
#define LOG_EQ(a, b) !((!!(a)) ^ (!!(b)))
Why is it necessary anyway? The result of ! is already guaranteed to
be either 1 or 0. Hence as Andreas said,
#define LOG_EQ(a,b) (!(a) == !(b))
In fact as far as I can tell these produce equivalent code on my system anyway:
8:logeq.c int
9:logeq.c log_eq_1 (int b, int a)
10:logeq.c {
16.loc 1 10 0
17.LVL0:
18.loc 1 10 0
19 85F6 testl %esi, %esi
20 0002 0F95C0setne %al
21 0005 85FF testl %edi, %edi
22 0007 0F94C2sete%dl
23 000a 31D0 xorl%edx, %eax
24 000c 0FB6C0movzbl %al, %eax
11:logeq.c return !a == !b;
12:logeq.c }
25.loc 1 12 0
26 000f C3ret
27.LFE20:
28.size log_eq_1, .-log_eq_1
29.p2align 4,,15
30.globl log_eq_2
31.type log_eq_2, @function
32log_eq_2:
33.LFB21:
13:logeq.c
14:logeq.c int
15:logeq.c log_eq_2 (int a, int b)
16:logeq.c {
34.loc 1 16 0
35.LVL1:
36.loc 1 16 0
37 0010 85FF testl %edi, %edi
^LGAS LISTING /tmp/cczOkpUt.s page 2
38 0012 0F94C0sete%al
39 0015 85F6 testl %esi, %esi
40 0017 0F95C2setne %dl
41 001a 31D0 xorl%edx, %eax
42 001c 0FB6C0movzbl %al, %eax
17:logeq.c return !((!!a) ^ (!!b));
18:logeq.c }
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cut - lack of --merge-delimiters option
On Sun, Aug 31, 2008 at 6:10 PM, Jan Skowron [EMAIL PROTECTED] wrote: coreutils program cut could use a merge delimiters option. Common use case: ls -l | cut ... One needs to print 7-th column of ls -l to see all times of modifications. But there is no constant number of delimiters between column, eg: drwxr-xr-x 23 user group 4096 Mar 16 2006 user drwx-- 2 root root 16384 Dec 19 2003 lost+found merge delimiters option would help a lot in such cases. Without it users are forced to use gawk instead of cut. For this use case you should be using stat --printf or find -printf. Parsing the dates produced by ls is problematic anyway: ~$ ( LC_ALL=C ls -ld ~/source/rekall ~/source/SimCity ) drwxr-xr-x 3 james users 4096 Sep 1 02:09 /home/james/source/SimCity drwxr-xr-x 24 james users 4096 Mar 22 2004 /home/james/source/rekall James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: French accents
On Thu, Aug 28, 2008 at 5:51 PM, Dr. Aprahamian [EMAIL PROTECTED] wrote: Hello, I am having difficulty with file names that have French accents. For example the file.- AfficheJourn\351e\311tudeP\350reaveclogos-1.pdf exists but because it has the French e accent in its title the programme is not recognizing it. What to do? Unfortunately you have not provided enough information for us to help you. You didn't indicate what program you used, how you used it, what result you expected, or what result you got. You mention a programme without identifying it, so I am somewhat at a loss to understand what problem you are describing. Please try to be more specific when asking for help. At this stage my best guess is that you have configured your system for the UTF-8 character set, but your filename is actually in ISO-8859-1 or a related character set. But in the absence of detail, this is just supposition. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Requests
On Sun, Aug 24, 2008 at 10:16 AM, Marc Perkel [EMAIL PROTECTED] wrote: I'd like to ask again (you liked the idea but I'm not seeing it implemented) that on the utilities head ad tail that the -c option be not only in bytes but also in k,m,g as in 10k 200m 2g Already done! You should upgrade: $ for util in head tail; do for n in 1 1K; do echo $util: $n: $(head -c $n /usr/share/dict/words | wc -c); done; $util --version| head -1; done head: 1: 1 head: 1K: 1024 head (GNU coreutils) 6.10 tail: 1: 1 tail: 1K: 1024 tail (GNU coreutils) 6.10 James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request: split --first size to affect first output file
On Sun, Aug 24, 2008 at 3:08 PM, Dave Turner [EMAIL PROTECTED] wrote: Hi, Tape drives and their media are large and expensive so I use writeable DVDs for my backups instead. GNU tar can write an archive across multiple tapes, using up any remaining space on one tape before moving to the next, but it cannot do the same on a DVD. A possible solution is to use 'split' to cut up a backup into smaller files and distribute them across DVDs: Indeed. But there already exists software more specifically suited to this. See for example dar: http://dar.linux.free.fr/ James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: root
On Sun, Aug 24, 2008 at 10:43 PM, jrl [EMAIL PROTECTED] wrote: can't log in as root am using directions from forums FAQ bash: su-: command not foundis the error msg. There should be a space before the dash, if you use it at all. For more information see either man su or info coreutils 'su invocation' James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: UNIX join command bug
On Thu, Aug 21, 2008 at 4:45 PM, Guillaume Smits [EMAIL PROTECTED] wrote: Dear GNU, I have two files exactly identical composed of: 6 Fields, tab separated, with a /n That would be \n - I assume you mean ASCII LF. at the end of the line, sorted numerically on the key identifier (field #2). Here is the head of the files: File1 CHR SNP A1 A2 MAF NCHROBS 13 rs4 G A 0.0648148 216 7 rs8 T C 0.17216 7 rs16T C 0.475962208 ... File2 CHR SNP A1 A2 MAF NCHROBS 7 rs8 A G 0.2156749876 7 rs16G A 0.4771029870 7 rs19G A 0.3856289880 ... The first file is ~ 1,400,000 lines long The second file is ~ 330,000 lines long You're not making it easy for people to help you.You don't indicate what version of coreutils you are using.You don't provide a minimal example. You just tell us you have two vast inputs you won't show us that don't join in the way you expect. When I perform a very simple join command as follows: Join -1 2 -2 2 file1.txt file2.txt joinedfile.txt I obtain a joinedfile of ~213.000 lines in place of the expected ~322.000 lines (65% of the lines). The lines missing are scattered everywhere in the original files (at the beginning, middle or end). There is also no logic to find while considering the SNP identifier of the missing lines. For example a line which is missing is the following one: This is not a helpful example; 99% of join problems are caused by out-of-order input and you haven't provided a complete example that domenstrates the problem so that we can eliminate that possibility. I can't find any difference between the files (e.g., no hidden characters) or the key identifiers. The files are sorted in the same way, tabulated in the same way,... My guess is that this is not actually the case. The only difference is the number of lines (1.4 million in file 1; 300 thousands in file 2). While big, these line numbers should not be a limiting factor to the join command... (and why would be the missing line scattered all along the files?) Using a Perl script to print lines having the same field 2 identifier, I obtain the ~322,000 lines expected proving that it is nearly surely a join command bug. Question: Is there any trivial (or less trivial) explanation to this join command bug? Operator error? Try coreutils 6.11, which should notify you if the input is out of order - see the Info documentation for details. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Requests?
On Thu, Aug 14, 2008 at 9:44 PM, ROBERT DVORACEK [EMAIL PROTECTED] 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 as a delmiter instead of endlines, e.g. offsets are in bytes instead of lines. I haven't looked at the code for csplit, but most of the options it already has seem oriented toward text data. Of course in the worst case (of the change being awkward to make to the existing program) you could write a new program for this purpose. IIRC, gnulib has some efficient functions for searching for byte sequences in memory blocks. Sorry about that. I thought the first one got rejected because it wasn't plain text. Gmail is doing the caps lock thing. I'll try to fix it. The menu option Settings Accounts allows you to edit the name associated with your account. I can't think why it would be all-caps at all in your case, mine isn't. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -s but sorted
On Fri, Aug 8, 2008 at 4:50 AM, [EMAIL PROTECTED] wrote: 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 I agree. ~/tmp$ find . -printf '%7S %10s %4b %p\n' 1 40968 . 2.4e-05 512000512 24 ./foo 1 32768 64 ./nohole 1.04 102400 208 ./bigger-nohole ~/tmp$ ls -lhs total 148K 104K -rw-r--r-- 1 james james 100K 2008-08-08 08:25 bigger-nohole 12K -rw-r--r-- 1 james james 489M 2008-08-08 08:18 foo 32K -rw-r--r-- 1 james james 32K 2008-08-08 08:19 nohole ~/tmp$ ls -s1S total 148 12 foo 104 bigger-nohole 32 nohole ~/tmp$ ls -s1Sl total 148 12 -rw-r--r-- 1 james james 512000512 2008-08-08 08:18 foo 104 -rw-r--r-- 1 james james102400 2008-08-08 08:25 bigger-nohole 32 -rw-r--r-- 1 james james 32768 2008-08-08 08:19 nohole So from the above it looks like ls is doing just what the documentation says it should. What are you suggesting should be changed? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: delete and redirection
On Mon, Aug 4, 2008 at 2:34 PM, Fabien Carmagnac [EMAIL PROTECTED] wrote: Hello, I have a problem when I remove a file which is a redirection of the std output of a process: I launch a process and redirect output to file: [EMAIL PROTECTED] ./myprocess mylog.log This is somewhat dangerous. The stdout output of that program will be buffered and the stderr output will not. It is quite possible that you will see out-of-order results in that log file while normally one would want to use a log file as an unambiguous record of past events. Then (after a few days/weeks), I remove the mylog.log file, hoping the system will create a new fresh one. Somebody else already addressed the misconception here. [snip] After a few days, df gives 100% disk used but kdirstat (a gui tool to watch size of each folder recursivly), says 20%used. Yes, the log file has no name any more but it has not yet been deleted, since a process is holding it open. Then, if I reboot, df says 20%used also. So my question is : is there a way to rotate/remove/resize logs without: - reboot computer Obviously. Many Unix programs do this. One typically designs such programs to manage their own log file. A well-designed long-running program will also do other things to prepare for robust longevity, for example - disassociating itself from its controlling terminal - changing directory in order to avoid blocking the unmounting of filesystems Long-running programs are often designed to reopen their logfile when they receive SIGHUP. See for example the documentation for the logrotate tool to get some understanding of this. - stop process flishing in it Sorry, didn't understand this. The computer is used as a very critical node in our organisation (quick trading 24/24). In that case you should probably use more than one computer. Being physical objects, they can fail.But then I have no way of knowing if the cost of an outage in your environment would justify the use of a second computer, so feel free not to take my advice. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Remove documentation for deprecated --reply options of mv and cp.
* doc/coreutils.texi (mv invocation): remove documentation for mv --reply.
(cp invocation): Likewise.
---
NEWS |2 ++
doc/coreutils.texi | 24
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/NEWS b/NEWS
index dfe893c..ac4e82c 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,8 @@ GNU coreutils NEWS-*-
outline -*-
ls now colorizes files with capabilities if libcap is available
+ cp and mv: the deprecated --reply=X option is now also undocumented.
+
** Bug fixes
chcon --verbose now prints a newline after each message
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f60f9c7..d0bed0e 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7320,18 +7320,12 @@ cp --parents a/b/c existing_dir
copies the file @file{a/b/c} to @file{existing_dir/a/b/c}, creating
any missing intermediate directories.
[EMAIL PROTECTED] The --reply option was deprecated in 2005, and is scheduled to
[EMAIL PROTECTED] be removed in 2008. It is already missing from the --help
output.
@itemx @[EMAIL PROTECTED]@var{how}}
@opindex --reply
@cindex interactivity
[EMAIL PROTECTED] FIXME: remove in 2008
[EMAIL PROTECTED]: to be removed in [EMAIL PROTECTED]
-Using @option{--reply=yes} makes @command{cp} act as if @samp{yes} were
-given as a response to every prompt about a destination file. That effectively
-cancels any preceding @option{--interactive} or @option{-i} option.
-Specify @option{--reply=no} to make @command{cp} act as if @samp{no} were
-given as a response to every prompt about a destination file.
-Specify @option{--reply=query} to make @command{cp} prompt the user
-about each existing destination file.
+This option is deprecated.
@item -R
@itemx -r
@@ -8015,17 +8009,7 @@ If the response is not affirmative, the file is skipped.
@itemx @[EMAIL PROTECTED]@var{how}}
@opindex --reply
@cindex interactivity
[EMAIL PROTECTED] FIXME: remove in 2008
[EMAIL PROTECTED]: to be removed in [EMAIL PROTECTED]
-Specifying @option{--reply=yes} is equivalent to using @option{--force}.
-Specify @option{--reply=no} to make @command{mv} act as if @samp{no} were
-given as a response to every prompt about a destination file.
-Specify @option{--reply=query} to make @command{mv} prompt the user
-about each existing destination file.
-Note that @option{--reply=no} has an effect only when @command{mv} would prompt
-without @option{-i} or equivalent, i.e., when a destination file exists and is
-not writable, standard input is a terminal, and no @option{-f} (or equivalent)
-option is specified.
+This option is deprecated.
@item -u
@itemx --update
--
1.5.6.3
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Document the supported baud rates beyond 38400.
* doc/coreutils.texi (Special): Document the supported baud rates
beyond 38400.
---
doc/coreutils.texi | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d0bed0e..b0883d7 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -12334,13 +12334,29 @@ Print the terminal speed.
@item @var{n}
@cindex baud rate, setting
[EMAIL PROTECTED] FIXME: Is this still true that the baud rate can't be set
[EMAIL PROTECTED] higher than 38400?
-Set the input and output speeds to @var{n}. @var{n} can be one
-of: 0 50 75 110 134 134.5 150 200 300 600 1200 1800 2400 4800 9600
-19200 38400 @code{exta} @code{extb}. @code{exta} is the same as
-19200; @code{extb} is the same as 38400. 0 hangs up the line if
[EMAIL PROTECTED] is set.
+Set the input and output speeds to @var{n}. @var{n} can be one of: 0
+50 75 110 134 134.5 150 200 300 600 1200 1800 2400 4800 9600 19200
+38400 @code{exta} @code{extb}. @code{exta} is the same as 19200;
[EMAIL PROTECTED] is the same as 38400. Many systems, including GNU/Linux,
+support higher speeds. The @command{stty} command includes support
+for speeds of
+57600,
+115200,
+230400,
+460800,
+50,
+576000,
+921600,
+100,
+1152000,
+150,
+200,
+250,
+300,
+350,
+or
+400 where the system supports these.
+0 hangs up the line if @option{-clocal} is set.
@end table
--
1.5.6.3
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Document uptime.
* doc/coreutils.texi (uptime invocation): document uptime.
* TODO: uptime is documented now.
* src/uptime.c (print_uptime): Use fprintftime to print the time, rather
than printf. This should make the situation better for translations.
---
TODO |1 -
doc/coreutils.texi | 38 +++---
src/uptime.c | 26 ++
3 files changed, 53 insertions(+), 12 deletions(-)
diff --git a/TODO b/TODO
index c7bb820..18371b3 100644
--- a/TODO
+++ b/TODO
@@ -11,7 +11,6 @@ document the following in coreutils.texi:
mktemp
[
pinky
- uptime
Also document the SELinux changes.
Suggestion from Paul Eggert:
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index b47448f..e4ca5c2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -31,7 +31,6 @@
@c FIXME: the following need documentation
@c * [: (coreutils)[ invocation. File/string tests.
@c * pinky: (coreutils)pinky invocation. FIXME.
[EMAIL PROTECTED] * uptime: (coreutils)uptime invocation. FIXME.
@c * mktemp: (coreutils)mktemp invocation. FIXME.
@c * chcon: (coreutils)chcon invocation. FIXME.
@@ -124,6 +123,7 @@
* unexpand: (coreutils)unexpand invocation. Convert spaces to tabs.
* uniq: (coreutils)uniq invocation. Uniquify files.
* unlink: (coreutils)unlink invocation. Removal via unlink(2).
+* uptime: (coreutils)uptime invocation. Print uptime and load.
* users: (coreutils)users invocation. Print current user names.
* vdir: (coreutils)vdir invocation. List directories verbosely.
* wc: (coreutils)wc invocation. Line, word, and byte counts.
@@ -193,7 +193,7 @@ Free Documentation License''.
* File name manipulation:: dirname basename pathchk
* Working context::pwd stty printenv tty
* User information:: id logname whoami groups users who
-* System context:: date uname hostname hostid
+* System context:: date uname hostname hostid uptime
* Modified command invocation::chroot env nice nohup su timeout
* Process control::kill
* Delaying:: sleep
@@ -407,7 +407,8 @@ System context
* date invocation:: Print or set system date and time
* uname invocation:: Print system information
* hostname invocation:: Print or set system name
-* hostid invocation::Print numeric host identifier.
+* hostid invocation::Print numeric host identifier
+* uptime invocation::Print system uptime and load
@command{date}: Print or set system date and time
@@ -12786,6 +12787,7 @@ information.
* uname invocation::Print system information.
* hostname invocation:: Print or set system name.
* hostid invocation:: Print numeric host identifier.
+* uptime invocation:: Print system uptime and load
@end menu
@@ -13614,6 +13616,36 @@ the case.
@exitstatus
[EMAIL PROTECTED] uptime invocation
[EMAIL PROTECTED] @command{uptime}: Print system uptime and load
+
[EMAIL PROTECTED] uptime
[EMAIL PROTECTED] printing the system uptime and load
+
[EMAIL PROTECTED] prints the current time, the system's uptime, the
+number of logged-in users and the current load average.
+
+If an argument is specified, it is used as the file to be read
+to discover how many users are logged in. If no argument is
+specified, a system default is used (@command{uptime --help} indicates
+the default setting).
+
+The only options are @option{--help} and @option{--version}.
[EMAIL PROTECTED] options}.
+
+For example, here's what it prints right now on one system I use:
+
[EMAIL PROTECTED]
+$ uptime
+ 14:07 up 3:35, 3 users, load average: 1.39, 1.15, 1.04
[EMAIL PROTECTED] example
+
+The precise method of calculation of load average varies somewhat
+between systems. Some systems calsulate it as the average number of
+runnable processes over the last 1, 5 and 15 minutes, but some systems
+also include processes in the uninterruptible sleep state (that is,
+those processes which are waiting for disk I/O). The Linux kernel
+includes uninterruptible processes.
@node Modified command invocation
@chapter Modified command invocation
diff --git a/src/uptime.c b/src/uptime.c
index 9e3384f..5bdc230 100644
--- a/src/uptime.c
+++ b/src/uptime.c
@@ -36,6 +36,7 @@
#include long-options.h
#include quote.h
#include readutmp.h
+#include fprintftime.h
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME uptime
@@ -126,12 +127,10 @@ print_uptime (size_t n, const STRUCT_UTMP *this)
uphours = (uptime - (updays * 86400)) / 3600;
upmins = (uptime - (updays * 86400) - (uphours * 3600)) / 60;
tmn = localtime (time_now);
+ /* procps' version of uptime also prints the seconds field, but
+ previous versions of
Re: [PATCH] Document uptime.
On Mon, Aug 4, 2008 at 6:51 PM, James Youngman [EMAIL PROTECTED] wrote: +The precise method of calculation of load average varies somewhat +between systems. Some systems calsulate it as the average number of Sorry: calculate +runnable processes over the last 1, 5 and 15 minutes, but some systems +also include processes in the uninterruptible sleep state (that is, +those processes which are waiting for disk I/O). The Linux kernel +includes uninterruptible processes. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH 1/2] Support arbitrarily-long numbers with GNU MP.
On Wed, Jul 30, 2008 at 12:32 AM, Paul Eggert [EMAIL PROTECTED] wrote: James Youngman [EMAIL PROTECTED] writes: Although libgmp itself has no further dependencies other than the C library, this is still a large-ish extra dependency. Should we also introduce a --without-gmp option to configure? Yes, particularly if it's added to 'expr'. See the patch I posted yesterday. I also remember Jim mentioning something about supporting large numbers in expr. That seems feasible, though based on the number of discussions over the last year or two I would suggest that perhaps using GMP in seq might also be a win; thoughts? They'd both be wins, I'd say. Also test, right? Though that's lower priority. As far as I can see, the only places where test handles numbers are -lt, -gt, -le, -ge, -eq, -ne Here the comparison is done with strintcmp, which compares numbers without converting them from a string. That is, strintcmp already works to arbitrary precision. -l This introduces an integer constant, the value of which is the length of the following string /usr/bin/test -l foo -eq 3 ; echo $? 0 Here I believe there is no need for bignums; a size_t is wide enough to represent the size of any string, and the argument is a string taken from the command line. In fact the length is immediately printed and handled as for -lt and similar anyway. -t Here the following argument is a file descriptor. Since they need to be representible as an int, there is no need for arbitrary precision here either. So as far as I can see, test already supports arbitrarily long numbers in all the cases where it makes sense. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Credit Torbjorn Granlund as the author of the arbitrary-precision factorisation code.
2008-08-04 James Youngman [EMAIL PROTECTED] * src/factor.c: Credit Torbjörn Granlund as the author of the arbitrary-precision factorisation code. --- src/factor.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/factor.c b/src/factor.c index c7cd29e..ab3359b 100644 --- a/src/factor.c +++ b/src/factor.c @@ -16,8 +16,8 @@ /* Written by Paul Rubin [EMAIL PROTECTED]. Adapted for GNU, fixed to factor UINT_MAX by Jim Meyering. - Arbitrary-precision code adapted by James Youngman from factorize.c - of GNU MP, version 4.2.2. + Arbitrary-precision code adapted by James Youngman from Torbjörn + Granlund's factorize.c, taken from GNU MP version 4.2.2. */ #include config.h -- 1.5.6.3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Support arbitrary-precision arithmetic in expr.
This code has more instances of #if HAVE_GMP than I would like, but I thought it was important to be able to transition smoothly from native arithmetic to arbitrary-precision arithmetic. 2008-08-02 James Youngman [EMAIL PROTECTED] Support arbitrary-precision arithmetic in expr. * src/Makefile.am (expr_LDADD): Link expr against GNU MP. * doc/coreutils.texi (expr invocation): Describe --bignum, --no-bignum. Explain the new arbitrary-precision functionality. * NEWS: Indicate that arbitrary-precision arithmetic is now supported in expr. * src/expr.c (enum valtype): Added mp_integer, signifying a GNU MP number. (usage): Document the new options --bignum and --no-bignum which force and prohibit the use of arbitrary-precision arithmetic, respectively. (long_options): data structure for getopt_long, which we need to use to parse the options mentioned above. (main): parse these options with getopt_long instead of parse_long_options. (valinfo): Downgrade the numeric member of the union from intmax_t to signed long, since MP lacks functions for promoting an intmax_t to an arbitrary-precision quantity. (enum arithmetic_mode): Represents the current choice between --bignum, --no-bignum and the default (automatically switch from one to the other if needed). (integer_overflow): issue a more explicit error message indicating that MP is not available. (string_too_long): new function, emits a fatal error message for the case where an argument to the 'index' expression is too long for a string offset to be represented. (int_value): With --bignum, create the value as mp_integer rather than plain integer. (substr_value): factored out of eval6; implements substr. (freev): also destroy mp_integer values. Check that no mp_integer values exist if --no-bignum was specified. (printv, null, tostring): support mp_integer. (toint): new funtion for converting from string or mp_integer to integer. (getsize): extracts a size_t value from a VALUE object; used to implement substr. (promote): promotes a value from integer to mp_integer. (domult, dodivide): functions for multiplication and division, factored out of eval4. (doadd): addition/subraction function, factpred out of eval3. (eval3): support mp_integer types; call doadd. (eval4): support mp_integer types; call domult, dodivide. (eval6): support mp_integer offsets and lengths for substr and index. * TODO: Mention that expr supports arbitrary-precision arithmetic, and suggest that this might also be a good idea for seq and test. * AUTHORS (expr): Add James Youngman. --- AUTHORS|2 +- NEWS |5 +- TODO |4 + doc/coreutils.texi | 17 ++- src/Makefile.am|3 + src/expr.c | 655 +--- 6 files changed, 593 insertions(+), 93 deletions(-) diff --git a/AUTHORS b/AUTHORS index eab9bec..9c3d990 100644 --- a/AUTHORS +++ b/AUTHORS @@ -25,7 +25,7 @@ du: Torbjörn Granlund, David MacKenzie, Paul Eggert, Jim Meyering echo: Brian Fox, Chet Ramey env: Richard Mlynarik, David MacKenzie expand: David MacKenzie -expr: Mike Parker +expr: Mike Parker, James Youngman factor: Paul Rubin false: Jim Meyering fmt: Ross Paterson diff --git a/NEWS b/NEWS index dfe893c..0957757 100644 --- a/NEWS +++ b/NEWS @@ -19,8 +19,9 @@ GNU coreutils NEWS-*- outline -*- With this new option, after a short read, dd repeatedly calls read, until it fills the incomplete block, reaches EOF, or encounters an error. - factor accepts arbitrarily large numbers and factors them using - Pollard's rho algorithm. + If the GNU MP library is available at configure time, factor and + expr support arbitrarily large numbers. Pollard's rho algorithm is + used to factor large numbers. md5sum now accepts the new option, --quiet, to suppress the printing of 'OK' messages. sha1sum, sha224sum, sha384sum, and sha512sum accept it, too. diff --git a/TODO b/TODO index c7bb820..4b8b26e 100644 --- a/TODO +++ b/TODO @@ -156,6 +156,10 @@ remove all uses of the `register' keyword: Done. add a maint.mk rule remove or adjust chown's --changes option, since it can't always do what it currently says it does. +Support arbitrary-precision arithmetic in those tools for which it +makes sense. Likely candidates include seq, and perhaps test. +Factor and expr already support this. + Adapt tools like wc, tr, fmt, etc. (most of the textutils) to be multibyte aware. The problem is that I want to avoid duplicating significant blocks of logic, yet I also want to incur only minimal diff --git a/doc
[PATCH] Add support for configure option --without-gmp.
2008-07-30 James Youngman [EMAIL PROTECTED] * m4/gmp.m4: Add support for --without-gmp. --- m4/gmp.m4 | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/m4/gmp.m4 b/m4/gmp.m4 index c0d1091..1efecd8 100644 --- a/m4/gmp.m4 +++ b/m4/gmp.m4 @@ -11,10 +11,17 @@ dnl Written by James Youngman. dnl Check for libgmp. We avoid use of AC_CHECK_LIBS because we don't want to dnl add this to $LIBS for all targets. AC_DEFUN([cu_GMP], -[ - AC_CHECK_LIB(gmp, __gmpz_init, - [ - AC_DEFINE(HAVE_GMP,1,[Define if you have GNU libgmp (or replacement)]) - AC_SUBST(LIB_GMP,[-lgmp]) - ],) +[AC_ARG_WITH(gmp, +AS_HELP_STRING([--without-gmp], + [do not use the GNU MP library for arbitrary precision calculation (the default is to use it if it is available)]), + [cu_use_gmp=$withval], + [cu_use_gmp=auto]) + + if test$cu_use_gmp = auto; then +AC_CHECK_LIB(gmp, __gmpz_init, [cu_use_gmp=yes]) + fi + if test $cu_use_gmp = yes; then +AC_DEFINE(HAVE_GMP,1,[Define if you have GNU libgmp (or replacement) and want to use it]) +AC_SUBST(LIB_GMP,[-lgmp]) + fi ]) -- 1.5.6.3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Support the factoring of arbitrarily-long numbers with GNU MP.
2008-07-27 James Youngman [EMAIL PROTECTED]
Support arbitrarily-long numbers with GNU MP.
* m4/gmp.m4: New file; adds cu_GMP, which detects GNU MP.
* configure.ac: Use cu_GMP.
* src/Makefile.am: Link factor against libgmp if available.
* src/factor.c: Use GNU MP if it is available.
(emit_factor, emit_ul_factor, factor_using_division,
factor_using_pollard_rho, extract_factors_multi,
sort_and_print_factors, free_factors): new functions
for the arbitrary-precision implementation, taken from an example
in GNU MP.
(factor_wheel): Renamed; was called factor.
(print_factors_single): Renamed; was called print_factors.
(print_factors): New function, chooses between the single- and
arbitrary-precision algorithms according to availability of GNU MP
and the length of the number to be factored.
(usage, main): New options --bignum and --nobignum.
* coreutils.texi (factor invocation): Document new command-line
options for the MP implementation and update the performance
numbers to take into account the asymptotically faster algorithm.
* TODO: Removed item about factoring large primes (it's done).
* m4/gmp.m4: Add support for --without-gmp.
---
TODO |3 -
configure.ac |1 +
doc/coreutils.texi | 58 ---
m4/gmp.m4 | 36
src/Makefile.am|3 +
src/factor.c | 497 +++-
6 files changed, 533 insertions(+), 65 deletions(-)
create mode 100644 m4/gmp.m4
diff --git a/TODO b/TODO
index e7f0508..c7bb820 100644
--- a/TODO
+++ b/TODO
@@ -127,9 +127,6 @@ Changes expected to go in, someday.
an implicit --NO-dereference-command-line-symlink-to-dir meaning.
Pointed out by Karl Berry.
- A more efficient version of factor, and possibly one that
- accepts inputs of size 2^64 and larger.
-
dd: consider adding an option to suppress `bytes/block read/written'
output to stderr. Suggested here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165045
diff --git a/configure.ac b/configure.ac
index ac93e1c..e54479f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -244,6 +244,7 @@ AC_CHECK_DECLS([strsignal, sys_siglist, _sys_siglist,
__sys_siglist], , ,
#include signal.h])
cu_LIB_CHECK
+cu_GMP
# Build df only if there's a point to it.
if test $gl_cv_list_mounted_fs = yes test $gl_cv_fs_space = yes; then
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 76b22e4..54798fd 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -14359,36 +14359,52 @@ factor @var{option}
If no @var{number} is specified on the command line, @command{factor} reads
numbers from standard input, delimited by newlines, tabs, or spaces.
-The only options are @option{--help} and @option{--version}. @xref{Common
-options}.
+The @command{factor} command supports only a small number of options:
-The algorithm it uses is not very sophisticated, so for some inputs
[EMAIL PROTECTED] runs for a long time. The hardest numbers to factor are
-the products of large primes. Factoring the product of the two largest 32-bit
-prime numbers takes about 80 seconds of CPU time on a 1.6 GHz Athlon.
[EMAIL PROTECTED] @samp
[EMAIL PROTECTED] --help
+Print a short help on standard output, then exit without further
+processing.
[EMAIL PROTECTED]
-$ p=`echo '4294967279 * 4294967291'|bc`
-$ factor $p
-18446743979220271189: 4294967279 4294967291
[EMAIL PROTECTED] example
[EMAIL PROTECTED] --use-mp
+Forces the use of the GNU MP library. By default, @command{factor}
+selects between using GNU MP and using native operations on the basis
+of the length of the number to be factored.
-Similarly, it takes about 80 seconds for GNU factor (from coreutils-5.1.2)
-to ``factor'' the largest 64-bit prime:
[EMAIL PROTECTED] --nouse-mp
+Forces the use of native operations instead of GNU MP. This causes
[EMAIL PROTECTED] to fail for larger inputs.
[EMAIL PROTECTED]
-$ factor 18446744073709551557
- 18446744073709551557: 18446744073709551557
[EMAIL PROTECTED] example
[EMAIL PROTECTED] --version
+Print the program version on standard output, then exit without further
+processing.
[EMAIL PROTECTED] table
-In contrast, @command{factor} factors the largest 64-bit number in just
-over a tenth of a second:
+Factoring the product of the eighth and ninth Mersenne primes
+takes about 30 milliseconds of CPU time on a 2.2 GHz Athlon.
@example
-$ factor `echo '2^64-1'|bc`
-18446744073709551615: 3 5 17 257 641 65537 6700417
+M8=`echo 2^31-1|bc` ; M9=`echo 2^61-1|bc`
+/usr/bin/time -f '%U' factor $(echo $M8 * $M9 | bc)
+4951760154835678088235319297: 2147483647 2305843009213693951
+0.03
@end example
+Similarly, factoring the eighth Fermat number @math{2^{256}+1} takes
+about 20 seconds on the same machine.
+
+Factoring large prime numbers is, in general, hard. The Pollard Rho
+algorithm
[PATCH 1/2] Support arbitrarily-long numbers with GNU MP.
2008-07-27 James Youngman [EMAIL PROTECTED]
Support arbitrarily-long numbers with GNU MP.
* m4/gmp.m4: New file; adds cu_GMP, which detects GNU MP.
* configure.ac: Use cu_GMP.
* src/Makefile.am: Link factor against libgmp if available.
* src/factor.c: Use GNU MP if it is available.
(emit_factor, emit_ul_factor, factor_using_division,
factor_using_pollard_rho, extract_factors_multi,
sort_and_print_factors, free_factors): new functions
for the arbitrary-precision implementation, taken from an example
in GNU MP.
(factor_wheel): Renamed; was called factor.
(print_factors_single): Renamed; was called print_factors.
(print_factors): New function, chooses between the single- and
arbitrary-precision algorithms according to availability of GNU MP
and the length of the number to be factored.
(usage, main): New options --use-mp and --nouse-mp.
---
configure.ac|1 +
m4/gmp.m4 | 20 +++
src/Makefile.am |3 +
src/factor.c| 497 ++-
4 files changed, 483 insertions(+), 38 deletions(-)
create mode 100644 m4/gmp.m4
diff --git a/configure.ac b/configure.ac
index ac93e1c..e54479f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -244,6 +244,7 @@ AC_CHECK_DECLS([strsignal, sys_siglist, _sys_siglist,
__sys_siglist], , ,
#include signal.h])
cu_LIB_CHECK
+cu_GMP
# Build df only if there's a point to it.
if test $gl_cv_list_mounted_fs = yes test $gl_cv_fs_space = yes; then
diff --git a/m4/gmp.m4 b/m4/gmp.m4
new file mode 100644
index 000..c0d1091
--- /dev/null
+++ b/m4/gmp.m4
@@ -0,0 +1,20 @@
+# Tests for GNU GMP (or any compatible replacement).
+
+dnl Copyright (C) 2008 Free Software Foundation, Inc.
+
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl Written by James Youngman.
+
+dnl Check for libgmp. We avoid use of AC_CHECK_LIBS because we don't want to
+dnl add this to $LIBS for all targets.
+AC_DEFUN([cu_GMP],
+[
+ AC_CHECK_LIB(gmp, __gmpz_init,
+ [
+ AC_DEFINE(HAVE_GMP,1,[Define if you have GNU libgmp (or
replacement)])
+ AC_SUBST(LIB_GMP,[-lgmp])
+ ],)
+])
diff --git a/src/Makefile.am b/src/Makefile.am
index 65b20a2..f464a70 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -129,6 +129,9 @@ seq_LDADD = $(LDADD) $(POW_LIB)
# and the `nanosleep' reference in lib/xnanosleep.c.
nanosec_libs = $(LDADD) $(POW_LIB) $(LIB_NANOSLEEP)
+# for various GMP functions
+factor_LDADD = $(LDADD) $(LIB_GMP)
+
sleep_LDADD = $(nanosec_libs)
tail_LDADD = $(nanosec_libs)
diff --git a/src/factor.c b/src/factor.c
index 08fa2a5..9000424 100644
--- a/src/factor.c
+++ b/src/factor.c
@@ -15,12 +15,19 @@
along with this program. If not, see http://www.gnu.org/licenses/. */
/* Written by Paul Rubin [EMAIL PROTECTED].
- Adapted for GNU, fixed to factor UINT_MAX by Jim Meyering. */
+ Adapted for GNU, fixed to factor UINT_MAX by Jim Meyering.
+ Arbitrary-precision code adapted by James Youngman from factorize.c
+ of GNU MP, version 4.2.2.
+*/
#include config.h
#include getopt.h
#include stdio.h
#include sys/types.h
+#if HAVE_GMP
+#include gmp.h
+#endif
+
#include assert.h
#define NDEBUG 1
@@ -40,6 +47,278 @@
/* Token delimiters when reading from a file. */
#define DELIM \n\t
+static bool verbose = false;
+
+typedef enum
+ {
+ALGO_AUTOSELECT, /* default */
+ALGO_GMP, /* --use-mp */
+ALGO_SINGLE/* --nouse-mp */
+ } ALGORITHM_CHOICE;
+static ALGORITHM_CHOICE algorithm = ALGO_AUTOSELECT;
+
+
+
+#if HAVE_GMP
+static mpz_t *factors = NULL;
+static size_t nfactors_found = 0u;
+static size_t nfactors_allocated = 0u;
+
+static unsigned add[] = {4, 2, 4, 2, 4, 6, 2, 6};
+
+static void
+emit_factor (mpz_t n)
+{
+ if (nfactors_found == nfactors_allocated)
+factors = x2nrealloc (factors, nfactors_allocated, sizeof(*factors));
+ mpz_init (factors[nfactors_found]);
+ mpz_set (factors[nfactors_found], n);
+ ++nfactors_found;
+}
+
+static void
+emit_ul_factor (unsigned long i)
+{
+ mpz_t t;
+ mpz_init (t);
+ mpz_set_ui (t, i);
+ emit_factor (t);
+}
+
+
+static void
+factor_using_division (mpz_t t, unsigned int limit)
+{
+ mpz_t q, r;
+ unsigned long int f;
+ int ai;
+ unsigned *addv = add;
+ unsigned int failures;
+
+ if (verbose)
+{
+ printf ([trial division (%u)] , limit);
+ fflush (stdout);
+}
+
+ mpz_init (q);
+ mpz_init (r);
+
+ f = mpz_scan1 (t, 0);
+ mpz_div_2exp (t, t, f);
+ while (f)
+{
+ emit_ul_factor (2);
+ --f;
+}
+
+ for (;;)
+{
+ mpz_tdiv_qr_ui (q, r, t, 3);
+ if (mpz_cmp_ui (r, 0) != 0)
+ break;
+ mpz_set (t, q
[PATCH 3/3] Remove large-prime TODO item.
2008-07-29 James Youngman [EMAIL PROTECTED] * TODO: Removed item about factoring large primes (it's done). --- TODO |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/TODO b/TODO index e7f0508..c7bb820 100644 --- a/TODO +++ b/TODO @@ -127,9 +127,6 @@ Changes expected to go in, someday. an implicit --NO-dereference-command-line-symlink-to-dir meaning. Pointed out by Karl Berry. - A more efficient version of factor, and possibly one that - accepts inputs of size 2^64 and larger. - dd: consider adding an option to suppress `bytes/block read/written' output to stderr. Suggested here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165045 -- 1.5.6.3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH 1/2] Support arbitrarily-long numbers with GNU MP.
On Sun, Jul 27, 2008 at 10:25 PM, James Youngman [EMAIL PROTECTED] wrote: 2008-07-27 James Youngman [EMAIL PROTECTED] Support arbitrarily-long numbers with GNU MP. * m4/gmp.m4: New file; adds cu_GMP, which detects GNU MP. * configure.ac: Use cu_GMP. At the moment, the cu_GMP macro will always use GNU MP if it is available. $ ls -lh /usr/lib/libgmp.so.3.4.2 -rw-r--r-- 1 root root 253K 2008-04-09 08:23 /usr/lib/libgmp.so.3.4.2 Although libgmp itself has no further dependencies other than the C library, this is still a large-ish extra dependency. Should we also introduce a --without-gmp option to configure? I also remember Jim mentioning something about supporting large numbers in expr. That seems feasible, though based on the number of discussions over the last year or two I would suggest that perhaps using GMP in seq might also be a win; thoughts? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
