Re: (man|info) pages and --help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C de-Avillez wrote: So. Would it be an acceptable idea to add, to the '--help', a warning that this is *not* the full documentation? Say, like: This is an abridged documentation. The full documentation for blahblah is maintained as a Texinfo manual. If the info and date programs are properly installed at your site, the command info coreutils 'blahblah invocation' should give you access to the complete manual. Is there anyone who's unaware that --help doesn't provide complete documentation? I can't think of any program that provides complete document via --help; the closest is software like Subversion, Git or Mercurial, where they provide you access to extensive documentation via svn help command-style inquiries. Indeed, the whole point behind - --help is usually to generate very brief usage information. Though a shorter, one-sentence message directing the user to the full Texinfo documentation could be useful. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. Maintainer of GNU Wget and GNU Teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqyhyYACgkQ7M8hyUobTrEoSwCdHodPi2KGyRoodcQIPaK62wGw cHEAnj7sNx0iGvaIo+nLU2kgP8SDIX9W =ssgG -END PGP SIGNATURE-
Re: sed command not found bug in 8.04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake wrote: According to ratnaveni k on 7/6/2009 4:49 AM: Hello Ratnaveni, Dear Developer, I installed ubuntu 8.04 in laptop.i tried to install some crystallographic programs. for one program thre is an error sed comman not found and awk command not found. i installed it by apt-get command.But stll i am getting the same error. After recent Ubuntu releases there have been several people who have been asking about Ubuntu questions on this GNU Coreutils mailing list. 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! Funny how you've asked this probably a dozen or more times, and haven't gotten a response, yet. :\ However, since sed and awk were involved, the user may (depending on his level of understanding) have legitimately thought that the report should go here (well, at least for awk), so it might be coincidence that the OS is Ubuntu. To Ratnaveni: could you please tell us how you found this list, and why you thought it was the best place to report the problem? It's usually best to supply us with the actual text of the error that occurred, appearing in its original context. From the little information you've given us so far, the problem actually isn't awk or sed, but that the program (installer?) you're running is either using an invalid path to invoke them, or doesn't have the PATH environment variable set up correctly. But without more detailed information, it's impossible to know for sure what's going on. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. Maintainer of GNU Wget and GNU Teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSHNkACgkQ7M8hyUobTrHB2gCfQa/sKxILZqcCWD53jkhY0cuq JPgAn26L5KPPkvpDNRpMNgEr26bav41b =xjLc -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: du bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake wrote: [please keep replies on the list, so that others may chime in] According to Robin McAdam on 3/21/2009 7:26 PM: That warning was in place to warn of a future change in behavior. The change has now been completed, and you will not get that warning in coreutils 7.1. But if I guessed wrong, then you will have to be more explicit on how what you posted shows a bug (that is, give us more details on what actually happened vs. what you expected to happen). Documents\ and\ Settings/ is reported as both 1.5G and 4.5G Thanks for calling attention to that. From your original report, xpu...@amdxp2100:/mnt/160G-1$ du -s --si * Documents\ and\ Settings/ ... 4.5GDocuments and Settings ... 1.5GDocuments and Settings/ I can explain why it is listed twice - you listed it twice on the command line (once via * without a trailing slash, and once and via explicit naming with the slash). But I'm not sure why the two values are coming back differently. Maybe an experiment on a smaller directory is in order? Maybe someone else can point to something to look at? It's a small thing, and may be just a red herring, but I'd be curious whether there's a difference in reported size for with and without a trailing slash; since he explicitly gave it with a slash, and the * would've given it without (as seen above), it might be interesting to see if there are different results between those two. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. Maintainer of GNU Wget and GNU Teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknF2XwACgkQ7M8hyUobTrFs0ACdFg4O1ayh2ZyQe0LpQm06IU+d IhUAnjPKotaOMM7Blt170xl+Wthv5lnJ =UqoH -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #25946] mv/cp/ls/cd cannot cope with leading dash (-) in directory names without path
Follow-up Comment #1, bug #25946 (project coreutils): cd -- - test - should also work fine. This is not only expected behavior for cd and ls, but for virtually any command on a Unix-style system. Arguments that begin with a - are interpreted as strings of options (think of ls -ltc), so cd (via the getopt library function) believes you are trying to pass it a string of options that includes (among other things) the space character. That's why the special -- argument exists: it tells getopt to treat any following arguments as true program arguments, and not as options. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25946 ___ 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: [md5sum]
Matthew Woehlke wrote: Pedro Henrique Marques wrote: But the output shows the verification only from the 3� to last file: To clarify, the problem is that the first and last file were apparently ignored? And second, I think. It would've been helpful to see the exact invocation of md5sum... -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug eepc think virus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Hey there, I have some folders on my eeepc, which I cannot modify (wanted to delete them) Think it is a Virus. am not able to run the usual Llinux Desktop. Instead there is a black screen with the Taskbar underneath. Not able to shut down the eeepc. Not able to click the SOS Button or the EEPC Tips Here the Console Window I ran to modify. I am quiet new to this whole Eeepc and Linux stuff. Maybe it is not serious and I am just not able to do the RIGHT things. Smile to you Marianne Sounds like you should seek support from the EEEPC folks. That's not this group. But rest assured, the odds of it being a virus are quite low. chmod: missing operand Try `chmod --help' for more information. /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ chmod --help Usage: chmod [OPTION]... MODE[,MODE]... FILE... or: chmod [OPTION]... OCTAL-MODE FILE... or: chmod [OPTION]... --reference=RFILE FILE... snip Report bugs to bug-coreutils@gnu.org. /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ /.rw/_497dadb6-47d6-4a30-8c0c-a0360140c548_ This _is_ the group for reporting bugs on chmod. However, nothing you've shown so far indicates a problem with the chmod command-line program. It's not even clear what you were trying to do with chmod, so we can't know how to help you to do it. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkaTV0ACgkQ7M8hyUobTrFBoACggufzpo0wRsVFXfpPGmz2joTh 5ewAn35hHt/oiVBrZWgkLlKUK+iOmQL4 =v3cM -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Tail Variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Wright wrote: I hope this is the right place to post this question.I'm running Puppy Linux 4.0 and have run into a problem with their version of tail not supporting the --byte option. I have to use -c instead. Is this because it's not a standard GNU version of tail? Is there a version of GNU tail that doesn't support the -c option? I ask because I want to know if it's safe to switch from the --byte option to the -c option in a script and still have it be portable across all distributions.Thanks. Should be pretty portable, -c is POSIX, and, judging from the rationale section, historical as well. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIsc5j7M8hyUobTrERAgjPAJ9GCf6RDLFRBQ89wTc9IwLW8ohGjQCfWHqu QZbC2AdkbksKjk38V+N488s= =2jU8 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BUG I Think !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmad Hussein wrote: Hi ,, Unknown man ;) ,, OK i have problem in the terminal when i write this command sudo apt-get install * it's appear this message E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. ,, so what should i do ? please give me answer ,, Well, I might recommend you follow the instructions given there. Apart from that, neither dpkg nor apt-get have anything to do with GNU coreutils, which is the focus of this mailing list. You'll do much better to ask on a forum dedicated to your OS (Debian, Ubuntu, or what have you). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIolue7M8hyUobTrERAqTxAJ9aa15MMMhBYq2b7Vpq68eozR7w7gCbBgIa hZ0EaONCNhUpmn0IGBt2HqU= =/6Zb -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tiny string fixes [patches]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Meyering wrote: Benno Schulenberg [EMAIL PROTECTED] wrote: Hi, While updating the Dutch translation for coreutils, I came across a few small inconsistencies. Attached patches fix those. Hi Benno, Thanks for all the patches! Starting with the last one... - _(EXIT_STATUS == EXIT_SUCCESS -? Exit with a status code indicating success. -: Exit with a status code indicating failure.)); + EXIT_STATUS == EXIT_SUCCESS + ? _(Exit with a status code indicating success.) + : _(Exit with a status code indicating failure.)); I'd like to keep it so there's just one gettext call, so solved the problem slightly differently: Here's what the ISO C standard says about the conditional operator: «The first operand is evaluated; there is a sequence point after its evaluation. The second operand is evaluated only if the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0; the result is the value of the second or third operand (whichever is evaluated), converted to the type described below.)» Of course, it's still possible that the resulting code will contain two distinct places where gettext is called; but in any case there will be only one actual call. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIl6dS7M8hyUobTrERAg93AJ9SySIe75lgVyGbZ2EEm80NLWL9CwCfRWiC UyvlCwFQqLswmSas6NWa0U0= =5Utw -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: delete and redirection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabien Carmagnac wrote: Hello, Hi. Your question (and its potential solution) isn't really topical for this forum (which is for discussion of the GNU coreutils software package). It involves the use of a part of that software (rm, and apparently bash), but it doesn't have much in particular to do with it. If you continue to have problems after the explanation and suggestion here, you should probably take it to a forum dedicated to support for your system. 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 Then (after a few days/weeks), I remove the mylog.log file, hoping the system will create a new fresh one. [EMAIL PROTECTED] rm -f mylog.log But the system never created again the file. Why would the system create a fresh one? You asked it to get rid of it. After a few days, df gives 100% disk used but kdirstat (a gui tool to watch size of each folder recursivly), says 20%used. The process is still writing to the file, even though it doesn't have a directory entry (link) anywhere. So long as a process has it open, a file exists until both the processes that have it open are terminated, _and_ it no longer has any links in the filesystem. 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 - stop process flishing in it Nope. What I'd suggest is have the process's output pipe to a program whose responsibility is to read a line, open the log file, append the line to it, then close it. Something like: #!/bin/sh set -u : $1 IFS= while read -r LINE do echo $LINE $1 done Then you would run ./myprocess | /path/to/script mylog.log Removing or rotating the mylog.log file would then still permit the next line to appear in a new mylog.log. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIl6/s7M8hyUobTrERAgZXAJ4mOsaaldPmHjdCYz6TqbcSeEfxOQCdE0/n jkhX9PY1ndlVdUexphemVVo= =75Oe -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip Susi wrote: Jim Meyering wrote: When I say not affected I mean it. Turning off the readdir optimization affects ls -i only when it reads directory entries. You mean you are only disabling the optimization and calling stat() anyway for directory entries, and not normal files? He means that there _is_ no optimization. When you're applying ls -i directly to files (ls -i non-directory, the scenario he mentioned as not being affected), there is no readdir, there are no directory entries, and so there is no optimization to be made. A call to stat is required. There is no effect to reduce. I may be completely off-base here, but that's how I read it, at least (how do you get inode info from dir entries you don't have?!). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfU1z7M8hyUobTrERAk4cAJ0Uk3ZmOSlB24I4c0Rizd5J3VcnaACfSg6b qj/aK8q8tB2iI3E1lTPX9Nk= =0Loq -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: echo -e bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Panin wrote: Hi! I can't make echo to show \n and \r symbols. According to 'man echo', there's a way to do this by using '-e' option. However, this doesn't help. Doesn't even matter which option I choose (even 'echo -e \015'), it just shows '015' literally. More likely, shell interpretation. The shell will turn a bare \015 into 015. Try quoting it, such as with '\015' or \\015. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIa6Yd7M8hyUobTrERAuGWAJ9qMK0eAqzi6VFYN9ciuXGoX1pOnQCfX3rU Yxce1wcigJKUviZcnBFHeUk= =/M09 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: updates installation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake wrote: According to huma fouladi on 6/4/2008 12:02 AM: | Dear sir | | I am facing problem using update manager,it only shows updates but cant | download. | Kindly sort out the problem and let me know what to do. You reached the coreutils list, but coreutils does not provide an update manager. You didn't even mention which system you are having the problem on, so I can't even recommend a particular users group or distribution mailing list that might be a better resource to help you in your problem. I'll hazard a guess, and suppose you (huma) might possibly be talking about Ubuntu's Update Manager? In that case, I might suggest you use your IRC client (look in your Applications menu for Internet - X Chat) to ask on the #ubuntu channel. Please be patient, as it is volunteer-run, and the volume of questions there are quite high. There is also the [EMAIL PROTECTED] mailing list: http://lists.ubuntu.com/mailman/listinfo/ubuntu-users Response times may take a bit longer there. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIR0BY7M8hyUobTrERAiPMAKCNW38Lr9QdpJQ3JtA4lNnsl27t0ACdFrot 0Fkz7SQyJeVOCU/RW1eI00o= =DRYK -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: OO 2.2 freezes repeatedly on Freespire 2.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Rowlands wrote: On Thu, 1 May 2008, Kenneth Koym wrote: Attn: Bug-coreutils@gnu.org Repeatedly, OO 2.2 has froze while saving a document; often this happens just as I open and select a line or two for placing in another document or place it in an email for sending. Then, I have to spend hours and hours to resolve the glitch. Last night I said, before going to bed, this is the latest response in the terminal mv: cannot move `/root/.openoffice.org2' to a subdirectory of itself, `/root/.openoffice.org2_backup/.openoffice.org2' what causes this? What version of coreutils to you have installed? The bug here is the misleading error message from mv as /root/.openoffice.org2_backup/.openoffice.org2 is not a subdir of /root/.openoffice.org2 Wonder if the former is a symlink to the latter, and the backup wasn't created quite right... - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIGr7k7M8hyUobTrERAkZ8AJ47rhH+SxQVSonQggEjDE5Ddum/TgCfdmVs tl7JRRvye2jdeEe0LnAPpdQ= =rITt -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Not a bug, a wish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Samuel GRANJEAUD - IR/IFR137 wrote: Hello, I thank you very much for devolopping coreutils that allows quick and simple replacement of SQL queries and check. What I would appreciate is a tool that does head and tail in one command, giving the top and bottom lines from a piped output. Do you literally mean just the one top line and one bottom line? That could easily be achieved with the sed command: sed -n '1p;$p'. If you need more lines, sed can still do it, but requires a bit more work. You might look to a simple solution in awk/Perl/your-scripting-language-of-choice. - -- HTH, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6s8H7M8hyUobTrERArSOAJ9rBMUJuI8qRcyHWLx95UM8o8aUhACeIcGM cT8GeCpjotLFHLQRI1ogEYI= =SHiW -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure [with . at beginning of PATH]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Meyering wrote: PATH is a personal preference. Many people set it like I do. Don't expect that PATH is set like you prefer it. I'd argue that few people put . anywhere in PATH, since doing so constitutes a well-known security risk. I'm surprised that you would put . before directories like /usr/bin. I suppose one should point out, at this juncture, that default installations of OpenBSD have . at the end of their definition for PATH, in non-root accounts. Apparently, their rationale is that it's not too bad, and is better to do it a semi-okay way themselves in a default install, than to let users do it themselves, running the risk that they uncluefully PLACE IT AT THE FRONT. I don't write this to invite flames or discussion on whether OpenBSD's practice (or Bruno's) is an advisable one, or to encourage a debate on whether . should be in the PATH at all. But, when a set of developers who have a reputation for being secure by default opt for a default configuration that is traditionally considered by many to be less-than-secure, for the concern that some people might do something that pretty much _everyone_ believes is insecure, it would seem very, very advisable to avoid the latter. See the OpenBSD thread at http://article.gmane.org/gmane.os.openbsd.misc/100581 Again, I'm not trying to start a flamewar here; if you read the thread there and still feel that your practice is safe, no need to argue the point here. And I'll concede that the issue is much less serious for people who are the sole user on the system in question. I just wanted to point out that, AFAICT, there's no pros, and significant cons, to placing . at the head of PATH. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHruGM7M8hyUobTrERAmadAJ4yrfOibwg709AjUPNbIPYAlRJJAgCdFV9z UqqV6GohaHgY+NAV+RI+OKk= =bnsQ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: piping tail -f through cut
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pádraig Brady wrote: Bob van Loosen wrote: Hi everyone, Whenever I do this: tail -f /var/log/kern.log | cut -f 8- -d | dd bs=1 I get no output, but when I do this: tail -f /var/log/kern.log | cut -f 8- -d I do get output, I'm using coreutils 5.97 on Ubuntu 7.10 64 bit. I've documented that exact case here: http://www.pixelbeat.org/programming/stdio_buffering/ There's a patch for `cut` there, which demonstrates how to add this functionality to coreutils. Personally I think it would be great to add the buffering control to glibc, so that most applications would benefit. But Ulrich Drepper sarcasmin his usual amiable style/sarcasm suggested this was a silly idea. It is a very silly idea, considering it would violate the C standard (§7.19.3#7): As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrJCs7M8hyUobTrERAj+kAJ9p719TmoPlOgJFHkG9hfio/4GUuwCePVxk C3ej5YbZadYuyoweKlLZ//M= =79+4 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 5.97: Adjust mkdir message (File exists)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jari Aalto wrote: Thanks, but File exists is just the English version of the strerror(EEXIST) string from the C library. Target exists would be more generic if message is based on the EEXIST error code. Considering that, as Jim points out just below, directories and symlinks are also files, how would target be any better? File is quite generic enough, without being as vague in meaning as target is (and I thought you were arguing for more specificity?) (Jim:) For one thing, in discussing file system objects, file is often used to refer to a generic object, be it symlink, block device, regular file, directory, etc. ... I'm inclined to say no, but there is precedent for examining the file type. The prompt you see when using rm's -i tells you about the type of the file it might remove. Sure; but then, it's asking whether you want to destroy something; the more information about what you're potentially obliterating, the better. In this case, mkdir's telling you it can't create a directory because something else is already there. Does it really matter what specific thing is there? Perhaps it's a directory, perhaps it's a file; it doesn't really matter, because regardless of what it is, you're not going to clobber it with a directory. Perhaps, in addition to performing an lstat(), mkdir should go ahead and ls -lR it (if it's a directory), or page it for you (if it's a text file), so you can make the most-informed decision as to whether to remove it and try again. :) At any rate, I suspect the realm into which this suggestion falls was probably clarified, once it was accompanied with the suggestion that mkdir generate a logfile. Given that there's no historical precedent for it, the message is accurate as it stands, and no one has established what benefit a change could provide, it seems to me that the burden of proof is a long way from being met. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhIbd7M8hyUobTrERAqMFAJ0ds6kGhU8anYer1nEZPtQIjZHn0ACeLcSn EKM4zbKQecQmvjLrCxvXf7Y= =fK8D -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tr '[:upper:]' '[:lower:]' -- misaligned construct
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Meyering wrote: Here's a tentative patch that also avoids repeated (and wasteful) initialization of the xlate array. I note that POSIX requires that, in the case that the arguments are exactly '[:lower:]' and '[:upper:]' (or the reverse of the same), tr is actually supposed to ignore the 'lower' and 'upper' character classes, and instead initialize the mapping from the locale's tolower/toupper definition. This would have avoided the length mismatch in the first place, and while that issue appears to be addressed, tr still does not conform to POSIX, as, if tr were to encounter a locale definition file with an LC_CTYPE category definition such as the following: ... upper A;...;Z lower a;...;z tolower (A,Z) ... This would require $ echo | tr '[:upper:]' '[:lower:]' to output (though it isn't even lowercased), rather than ''. While the example above is, of course, contrived, there may well be locales where the tolower/toupper mappings differ from the longest possible mapping between the 'upper' and 'lower' classes. In fact, as it currently stands, I expect tr mishandles a case such as: $ echo σιγμας | tr '[:lower:]' '[:upper:]' (Note the two variants of sigma in there, which both have a single corresponding capital letter; I'm afraid I can't actually verify this is broken, as my work desktop is not set up to compile coreutils, and I lack the time to correct this for now; the stock (old) tr on the system, running Fedora Core 6, silently passes it through without conversion.) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgnQ07M8hyUobTrERAj1OAJ4sH0pvLyWRPm0A5HOybsVjaI2HLQCeJQ8X DEuKSy4u/ip63Df/UbC4FVY= =PC3H -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils ls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Proulx wrote: Vitaly V. Ch wrote: As I understand ls require null-separated format of output stream which will suitable for xargs. in this case I systematically use find instead of ls. Your message seems to be garbled and I, and perhaps others on the mailing list too, cannot understand what you are trying to say. If you have a bug please describe the problem such that we can recreated it. If you are requesting a feature then try to state the feature request in such a way that other people can understand it. Thanks. It reads to me like a request for ls to produce null-separated output, so that $ ls -0 . will produce output like $ find . -print0 -maxdepth 1 Vitaly: note that both find's -print0 and xarg's -0 are GNU extensions, and are not portable. And, if find does the job, then why do you need a second tool to be able to accomplish the same thing? - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHUIdv7M8hyUobTrERApeCAJ96OSHf2LaJ3rQPdPbK1BHMZucu9gCfchuW /UYB8IciNH7QH80O2p/XcNg= =NKV9 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: /bin/cat : argument list is too long
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Manickam Muthuraman wrote: Hello when i tried the following command, i get this error. May i know whats going wrong. [EMAIL PROTECTED]:~/HHpred/scop_hmm cat *.hhm scop70_1.72.hhm bash: /bin/cat: Argument list too long Hi Manickam, Eric pointed out that this is a system limitation rather than a bug. I'd like to also point out that the message is coming from bash, and not cat. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRGMj7M8hyUobTrERCPPiAJ98TQGKiv+aaCZxFn2UM/jA0j9vWwCfYMhi 6q82qeLAKEwK6alHbtUgNlo= =qdQx -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: hello
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ginis.com wrote: hello, how I can correct the time in RedHat Linux? with command time or date and how? Yes, date can do that. To make the change persistent, you probably also need the hwclock commands. Both will require root privileges to effect the change. See the documentation for those commands for further information. The time command is for timing how long a program runs; not for setting the system time. In the future, please try to choose a more descriptive line for your subject; many people choose whether or not to read (and answer) a message based on the subject line. It helps people to know what the topic of the message is, and how likely they are to have something to say. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQ2I67M8hyUobTrERCGNVAKCObmUEWDa+pGv9e1QbF83lmfAgoQCfY880 rj3gMa21J8SJonWzUbvDeN4= =S36I -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jim Meyering wrote: I'm sure you've already heard it, but I have to say it: You shouldn't use csh-based shells. If you ask anyone or google, you'll find many good reasons. Lack of a decent signal-handling mechanism is one of them. Jim, Usually when I hear this, it's in reference to shell scripting, and not interactive shell use. The famous Csh Considered Harmful article, for instance, is explicitly in the context of shell scripts, and not interactive use. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHK1zn7M8hyUobTrERCCx/AJ98q07a26xwTkSMcQZ5nLNGatkAbACeIkb9 AemM4lGRrbHpr/RVehQFRao= =ghCS -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Remove old CVS-isms from bootstrap.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jim Meyering wrote: Micah Cowan [EMAIL PROTECTED] wrote: +* bootstrap: Remove --cvs-user, CVS_USER, CVS_RSH; and test -d +CVS from version_controlled_file function. ... - if test -d CVS; then -grep -F /$file/ $dir/CVS/Entries 2/dev/null | - grep '^/[^/]*/[0-9]' /dev/null found=yes - elif test -d .git; then + if test -d .git; then git-rm -n $dir/$file /dev/null 21 found=yes else echo $0: no version control for $dir/$file? 2 Applied, but not that last hunk, so projects using CVS can still use this bootstrap script. Okay. I just removed that because the only place version_controlled_file appeared to be getting used was within gnulib/. I imagine in time we may want to add similar features for git; certainly I could see where specifying a different clone depth might be desirable. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHILne7M8hyUobTrERCAIFAJ4xbS/M8WWZDBvtFQ39DhAePE9fIwCfTVpK f6oTSMkduJ2Sxbo8+wMPtBs= =m9uD -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Update bootstrap to use the correct CVS path to fetch the latest gnulib sources.
cvs.savannah.gnu.org is no longer kept up-to-date, and should not be
used to obtain the latest gnulib sources; the CVS interface to the git
repo, at pserver.git.sv.gnu.org, should be used instead (or else just
use git).
* bootstrap: updated CVS path for gnulib sources.
---
bootstrap |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bootstrap b/bootstrap
index aa86d3d..1e655f4 100755
--- a/bootstrap
+++ b/bootstrap
@@ -243,7 +243,7 @@ case ${GNULIB_SRCDIR--} in
trap cleanup_gnulib 1 2 13 15
-cvs -z3 -q -d ${CVS_PREFIX}cvs.savannah.gnu.org:/cvsroot/gnulib co gnulib
||
+cvs -z3 -q -d ${CVS_PREFIX}pserver.git.sv.gnu.org:/gnulib.git co gnulib ||
cleanup_gnulib
trap - 1 2 13 15
--
1.5.2.5
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Update bootstrap to use the correct CVS path to fetch the latest gnulib sources.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: cvs.savannah.gnu.org is no longer kept up-to-date, and should not be used to obtain the latest gnulib sources; the CVS interface to the git repo, at pserver.git.sv.gnu.org, should be used instead (or else just use git). I ran into this when I ran cd po; make coreutils.pot on bleeding-edge coreutils, just after having done a bootstrap and configure. bootstrap was fetching the latest gnulib sources from the now-defunct CVS repository, and thus was not getting xprintf (which is in POTFILES.in). Specifying --gnulib-srcdir to point at my local copy did the trick. It might well be preferable to grab it using git now, instead of the CVS interface to git, since I imagine it's reasonable to assume that anyone hacking on coreutils from the repo has git. :) This patch was just the quickest-path-to-functionality. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH5Vo7M8hyUobTrERCKuCAJ9I9HqswNbbQGWbfUf4NQUZfEiavwCeNVgD q1QNWZ6bOsshPd3d6ae4aU4= =57mI -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Update bootstrap to use the correct CVS path to fetch the latest gnulib sources.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jim Meyering wrote: Micah Cowan [EMAIL PROTECTED] wrote: Micah Cowan wrote: cvs.savannah.gnu.org is no longer kept up-to-date, and should not be used to obtain the latest gnulib sources; the CVS interface to the git repo, at pserver.git.sv.gnu.org, should be used instead (or else just use git). I ran into this when I ran cd po; make coreutils.pot on bleeding-edge coreutils, just after having done a bootstrap and configure. bootstrap was fetching the latest gnulib sources from the now-defunct CVS repository, and thus was not getting xprintf (which is in POTFILES.in). Specifying --gnulib-srcdir to point at my local copy did the trick. It might well be preferable to grab it using git now, instead of the CVS Thanks for the suggestion. I'm definitely going to use git. Here's what I'm about to commit: git clone --depth 2 git://git.sv.gnu.org/gnulib || cleanup_gnulib That --depth 2 is to create what's called a shallow clone. No need to download all that history. Great. I had forgotten to include an actual ChangeLog entry, too, and was just in the midst of fixing that. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH5kK7M8hyUobTrERCG8iAJ9YPqBZEWZWLDTx+sO7Gy2HLtgV4QCeOzw2 WJJ9HQOvTd4J4l0ZTlc3lUA= =pcVH -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Errors in the coreutils-6.9 PO file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jim Meyering wrote: Eric Blake [EMAIL PROTECTED] wrote: According to Clytie Siddall on 10/24/2007 2:37 AM: Hi :) I recently reviewed our translation of coreutils for the Translation Project. I noticed the following errors, which I thought you might like to fix in an upcoming release: ___ 1. This is a fatal error for msgfmt: #: src/expr.c:133 #, c-format msgid \n ARG1 * ARG2 arithmetic product of ARG1 and ARG2\n ARG1 / ARG2 arithmetic quotient of ARG1 divided by ARG2\n ARG1 % ARG2 arithmetic remainder of ARG1 divided by ARG2\n A bare percentage sign in a c-format string will be reported as an error in the translation. But the string in question occurs inside fputs, not printf. So why is xgettext marking it as c-format? Bruno? It *used to be* a format string. Checking a .po file built from latest sources: $ grep -B6 ARG1.%.A po/vi.po|cut -c1-13 #: src/expr.c #, c-format snip Yes, it used to be a format string; however, does xgettext know this? That is, the generated coreutils.pot file itself has #, c-format in it (on my system, with stock xgettext 0.16.1 from Ubuntu 7.04). Does xgettext just see the % and think Oh, C format string? If so, perhaps the heuristic could be adjusted a bit... - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH5xB7M8hyUobTrERCN48AJ9RVwMeg5crlXY9fpoFZoxq+/wFwwCfXbPc 99CsK3kOaQ0iQNyco5gH7b0= =V+ye -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Errors in the coreutils-6.9 PO file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andreas Schwab wrote: Micah Cowan [EMAIL PROTECTED] writes: Yes, it used to be a format string; however, does xgettext know this? That is, the generated coreutils.pot file itself has #, c-format in it (on my system, with stock xgettext 0.16.1 from Ubuntu 7.04). Does xgettext just see the % and think Oh, C format string? If so, perhaps the heuristic could be adjusted a bit... % A is a valid c-format ... Doh! Of course you're right... I just never actually use the space flag character. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH7EL7M8hyUobTrERCKsfAJ454AZqDH3gIX5PNLPalIr56jQqbwCeLF6O jDnxpxEurfIPqrFOYN4VnAA= =z5eQ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Errors in the coreutils-6.9 PO file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric Blake wrote: According to Bruno Haible on 10/24/2007 4:44 PM: ARG1 % ARG2 arithmetic remainder of ARG1 divided by ARG2\n xgettext marks it as c-format, because it looks like a C format string, and the possible negative effects of doing so (a mail from translator to programmer is needed) are smaller than the possible negative effects of not marking it as c-format (program crashes in particular locales). To which I ask the (hopefully obvious followup) - if I don't like what the hueristics picked, then how do I explicitly tell xgettext that I am sure this is NOT a c-format, because it is used in fputs and not printf? Is there a magic /* xgettext: */ comment to do this? There is... and it was actually mentioned a couple times upthread, though not explicitly spelled out. You want: /* xgettext:no-c-format */ on the same line or on the line just prior to the string. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH/0A7M8hyUobTrERCMZqAJ9Dmlu0xA+Nq4Jg/BTz+YeDPqreEwCgicnv ywy1/Bu1Byq+vRlhCXCP62s= =F9cl -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Enable msgfmt to work with translatable strings from expr.c.
* src/expr.c (usage): Mark the string describing ARG1 % ARG2 as not being a fprintf-style format string, for xgettext. --- ChangeLog |5 + src/expr.c |1 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9377791..8537a59 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2007-10-24 Micah Cowan [EMAIL PROTECTED] + + * src/expr.c (usage): Mark the string describing ARG1 % ARG2 + as not being a fprintf-style format string, for xgettext. + 2007-10-24 Jim Meyering [EMAIL PROTECTED] Avoid diagnostics from sha1sum when there is no cached checksum. diff --git a/src/expr.c b/src/expr.c index c800065..f4189c6 100644 --- a/src/expr.c +++ b/src/expr.c @@ -128,6 +128,7 @@ separates increasing precedence groups. EXPRESSION may be:\n\ ARG1 + ARG2 arithmetic sum of ARG1 and ARG2\n\ ARG1 - ARG2 arithmetic difference of ARG1 and ARG2\n\ ), stdout); + /* xgettext:no-c-format */ fputs (_(\ \n\ ARG1 * ARG2 arithmetic product of ARG1 and ARG2\n\ -- 1.5.2.5 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in cat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cutler, David wrote:
Hello,
My execution environment is
CYGWIN_NT-5.1 DCUTLER 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin
(dual core, 2.0 GHz cpu with 2GB ram Compaq NW8440 Laptop)
When I downloaded Cygwin, I specified the use of DOS line terminators.
I found a bug in what I suspect is cat when used with a simple bash shell
script.
It's common to place a set of names into a file (one name per line) and then
use a for loop to walk through the list.
For example:
If a file named list contains
a001s2
a002s2
a003s2
a004s2
a005s2
a006s2
And you execute the command:
for I in `cat list` ; do echo \${i}\ ; done
The output is
a001s2
a002s2
a003s2
a004s2
a005s2
a006s2
Echo is printing literal \rs from the DOS-style CR LF line
terminators. Your terminal is interpreting \r (rightly) as move to
the beginning of the current line.
Cat is just spitting out the file's contents. It's not going to read
them as lines, just as data to spit out. If there's a bug, it's not
with cat. Talk to the Cygwin folks to find out what's going on. I don't
know, but it's possible something like
cat list | while read -r I; do echo \$I\ ; done
(which is more line oriented) will work better for you. Either way,
there's not much we can do for you here. Cat is just doing its job.
- --
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHHpYC7M8hyUobTrERCH7PAJ4tDY/OHHvk9moHoXR2PXb7LV9IKgCfaXXq
uxGKS1kY7f1YTGyh9kjXj+g=
=3pQ2
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: info foo should be info coreutils foo in man page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Reuben Thomas wrote: The man pages wisely direct the reader to the info documentation, but since coreutils's documentation is now in one big info file, info cat, for example, doesn't work (it gives me the man page again on my system); you have to say info coreutils cat. This is Debian bug #411722: http://bugs.debian.org/411722 That's actually an issue with Debian, not coreutils. Debian has had its own version of install-info; part of the dpkg package. This Debian install-info had failed to track with newer changes in GNU's install-info. GNU coreutils updates dir in such a way as to allow info cat to take you to the appropriate section in the coreutils info manual. It only works with GNU install-info, though. The last I heard, Debian was planning to migrate to using GNU's install-info, and remove the one from dpkg: http://lists.debian.org/debian-dpkg/2007/04/msg00031.html I do not know how far along this is. See https://bugs.launchpad.net/debian/+source/dpkg/+bug/38538 for additional information. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHRRp7M8hyUobTrERCDCWAJ9sv+O7rLu1LlHMCamURCa3ahjOwwCfWcLq EIL3gz7EkAGHA5GlA2cCGc4= =Bqfj -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: hi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 wisdom helegbe wrote: [EMAIL PROTECTED] ~]# ./configure --help -bash: ./configure: No such file or directory According to the prompt you show, it looks like you're trying to run ./configure from within your home directory, rather than from the source directory into which you unpacked coreutils. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGwnR7M8hyUobTrERCBzbAJ9YS9sDpsc0XbGQBkkwvWBLNE5JNACggdY1 UD6sFqC89x1iz7KdWaYjTdw= =XYuU -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bugreport for ChMod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael Gorbovitski wrote: chmod --help results in : help for chmod .. Each MODE is of the form `[ugoa]*([-+=]([rwxXst]*|[ugo]))+'. Report bugs to bug-coreutils@gnu.org. The above regular expression is unparsable by most people requesting the help. Heartily agreed. Ugly and unnecessary, IMO. Besides, we already have an at least marginally easier-to-grok version further up: [ugoa...][[+-=][rwxXstugo...]...][,...]. Though I'm not sure this shouldn't go, either. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHC9LW7M8hyUobTrERCHrsAKCMrq/I1+d+HQypnb8CM1gnB7wH3gCfZxA2 xESMcnxIfOIDU5Vt8ngTWPE= =5qLH -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -- -b
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bob Proulx wrote: A scan is made left to right across the argument list looking for options. Traditional behavior and POSIX require options before non-option arguments. As a GNU extension options may appear anywhere in the argument list. If a -- is encountered it is taken as the end of option processing. Any arguments that follow will not be parsed as a option. Because all of the programs that use getopt follow this convention it is good one to know for shell programming. Almost all of the programs that are used in shell programming such as rm, mv, cp, grep, sed, cat, etc. all use getopt for option processing and all behave the same way with respect to option processing. This is so fundamental that it almost can't be documented in each program because it would be replicated in almost every documentation page. This behavior is what I expect to see from every program and am disappointed when it is not the behavior. POSIX also has it in its Utility Conventions, and both requires this behavior of its core utilities, and recommends their use by authors of other utilities. Even though POSIX requires all options be specified before non-option arguments, it is still useful for cases such as the one in this thread's Subject. :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHAJrF7M8hyUobTrERCGvcAJ92Ebybppp6Sy7L9zg4bWEqIXR6rQCffE4q /V3CWb/h9chQgy1OwH1Orr4= =dAcl -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: su command requiry
熊途 wrote: hello: when I used su command to get into Linux by root in terminal windows, I can not input password. Another user name too.How can I resolve my problem.thank you! It may be that you're confused by the fact that the su command hides its input. That is, the characters you're typing will be used for the password, you just can't see them as you're typing them. This is done to protect your password from people who might be looking over your shoulder. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Text tools, line endings, and O_TEXT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John Cowan wrote: Indeed, I'd like to see all text tools accept all six known line ending conventions: CR+LF, CR alone, LF alone, NEL alone, CR+NEL, LS. (NEL is U+0085, LS is U+2028.) snip That said, I believe it is good for portability to use O_TEXT and O_BINARY (and their stdio equivalents) in all software intended to be portable. Unix-tradition systems won't benefit, but it doesn't cost anything either; other systems will be enabled to DTRT as a result. If you intend for all text tools to recognize all line endings, wouldn't it be better to always open in binary mode so the program can handle the line-endings? Relying on the system to translate _some_ line-endings seems problematic, since you won't know which (if any) the system will handle. The original could have been CR+CR+LF, with the system translating it as CR+LF, or even LF+LF+LF (some versions of Mac OS?), and you wouldn't be able to tell the difference. BTW, are there systems that use CR+NEL as their canonical line terminator, and if so, which ones? That seems silly, since AFAICT NEL was intended to replace CR+LF (ISO-6429/Ecma-048 defines it as moving to to the line home position of the following line, adjusting for implicit movement direction). But then, I'm not even familiar with systems that use NEL as a line terminator in the first place, so my ignorance is not at all surprising. ;) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4Dv97M8hyUobTrERCO6iAJ9GUkHNguGsI4HSLe+Zv+R+4RANjQCeJRB7 sut0YDPbVzMqXYaS4l+vaJ0= =9WqM -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Error with Update Manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Joost Brands wrote: Unknown Error: 'type 'exceptions.SystemError'' (E: The package skype needs to be reinstalled, but I can't find an archive for it)* This error line appeared after I tried to install a beta version of Skype software. Since then it is impossible to install either software or updates. The update manager quits as well. What can I do? (I'm very unexperienced with Linux, however, a few weeks ago I bought a laptop with Ubuntu on it and I like it :-) ) Hi. Um... neither Skype, nor Ubuntu's Update Manager, nor Ubuntu itself, have anything in particular to do with the GNU coreutils package, which is the exclusive topic of this forum. I'd recommend you contact the Ubuntu community for help with this. You can find them on IRC in the #ubuntu channel on irc.freenode.net; or join the Ubuntu tech support mailing list at https://lists.ubuntu.com/mailman/listinfo/ubuntu-users When you do, please be patient, as these are volunteer-(under-)staffed resources. Please feel free to post to this forum in the future, if you are experiencing problems with the GNU coreutils package and believe that the problems are not do to custom changes made by the Debian or Ubuntu developers. Do please try to do a little due diligence first, though, to ensure that you are asking your questions in the right place! - -- Thanks, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGqiph7M8hyUobTrERCMO6AJ42kV0gh90SKPJj/TLWmEMUEuF9uQCdHW26 VPjgD7DCGlblbsVyu8VoapI= =FDx7 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] SEQ BUG
f making seq act as if it were counting in decimal for fractions, instead of binary floating-point, is really something we want to consider, then why don't we actually have seq represent fractions in decimal, internally? Isn't that the only real way we could possibly expect seq to do what the user expects in every case? Possibly, this should be configurable via a flag (especially since doing calculations in decimal would be significantly slower than the current system). I'd be leaning towards requiring a flag in order to do decimal, but of course, that wouldn't save us from having to deal with why didn't it print 1.9 requests; it would just replace the usual lengthy explanation with a give the ... flag to make seq do what you want. -- My 2¢, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls should not color output when --color=auto is used in environment TERM=dumb
Lenny Domnitser wrote: On 6/13/07, Bob Proulx [EMAIL PROTECTED] wrote: Improving this seems like a reasonable enhancement. If you think changing the behavior of --color=auto will break things, I can do --color=smart, i.e. the TERMinal is not dumb. Given that dumb isn't the only terminal type that doesn't support color, and that dircolors ostensibly knows (non-comprehensively) which ones do, I'd still vote for letting dircolors do the term detection (that it already does), and have ls handle a set-but-empty LS_COLORS accordingly. For my part, I'm having a hard time envisioning any problems that could be caused by using --color=auto for this; at least, exporting an empty LS_COLORS when one means for ls to rely on its default color settings seems an unnatural idiom: leaving LS_COLORS unset (for instance, by neglecting to evaluate dircolors' output) seems a much more natural idiom, and I would hope that's how people who want the defaults are already doing it. Additionally, if there are some people who are using the method that will become broken, it will be easy to fix, and will not cause any loss in functionality or breakage elsewhere, since it is inconceivable that scripts parsing ls's output would be relying upon ls to output some particular color sequences (or, even any color sequences). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup feature request / Please fwd to Jim Meyering
Phillip Susi wrote: trap 1 15 if test -t 21 ; then echo Sending output to 'nohup.out' exec nice -5 $* nohup.out 21 else exec nice -5 $* 21 fi All that nohup does is to ignore SIGHUP and SIGTERM and redirect the output if it is not already redirected. Before job control this was all that was needed to avoid a controlling terminal disconnection from killing the process. Unfortunately with job control a little more is needed. Trapping the signals in the shell does not trap them in the exec'd child program, so I don't see how this would work. Untrue, actually: _handling_ the signals would not handle them in the exec'd child (for obvious reasons), but POSIX requires blocked signals to remain blocked after an exec. Try the following: #!/bin/sh trap TSTP exec yes /dev/null and then try suspending the program with ^Z, with and without the trap line commented out. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: An error
Johannes Findeisen wrote: Hi, On Wed, 2007-06-13 at 16:47 -0400, Dhruv Rangoonwala wrote: Hi, I have tried to use the following command: cat -b anyFileName If the file have blank lines, this command does not eliminate it. It still gives number to that blank line. Please check it. Which version of core-utils are you using? I can't reproduce it here. Could it be that there are whitespaces in the blank lines? A quick an' easy way to check would be to view the output of: sed -n l anyFileName which will show the end of each line with a $. If the $ is not flush to the left of the terminal, you have blanks in that line. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup feature request / Please fwd to Jim Meyering
Andreas Schwab wrote: Micah Cowan [EMAIL PROTECTED] writes: Untrue, actually: _handling_ the signals would not handle them in the exec'd child (for obvious reasons), but POSIX requires blocked signals to remain blocked after an exec. trap is not about blocking a signal, but ignoring it. Yeah, my terminology's apparently not so great today: exec'd child is another goof (s/b exec'd process). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls should not color output when --color=auto is used in environment TERM=dumb
Bob Proulx wrote: Lenny Domnitser wrote: It works fine, but it seems that it's a workaround for behavior ls could have. Since ls already has so very many features adding more features requires a higher activation energy than adding features for other commands. For something conceptually very simple the ls command has become a very heavy application. I would expect virtually every application that sends special terminal control sequences (such as those used for coloring) to respect the TERM variable and relevant terminal databases; it's just good manners. OTOH, making /bin/ls rely on ncurses is obviously be a bad thing. dircolors, OTOH, already /has/ its own terminal database built-in, which can be adjusted by passing it files. And, in fact, dircolors will give LS_COLORS='' if TERM=dumb, since it recognizes that it's not a color terminal (or more accurately, fails to recognize it as a color terminal in its database). It seems to me, then, that ls should never colorize in the case that LS_COLORS is /set/, but has a null value. Then the proper thing to do in a .bashrc is to simply ensure that dircolors' output is eval'd before invocation of a colorizing ls, and let dircolors/ls just DTRT. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Patrick Amstutz wrote: Hi, I've the following behavior with the seq function on: Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version 4.1.220061115 (prerelease) (SUSE Linux)) #1 $ echo `seq 0.0 0.1 0.8` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 $ echo `seq 0.0 0.1 0.9` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 Actually, not a bug. This behavior is described in the info manual (info seq or info coreutils seq), and has to do with the limitations of binary floating point types; look for the line starting Be careful when using `seq' with a fractional INCREMENT. You need to use something more like: $ echo `seq 0.0 0.1 0.91` 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: SEQ BUG
Pádraig Brady wrote: Another thing I just noticed. I would expect the precision of all output in the following command to be to 2 decimal places not 1: $ seq 0.00 0.01 0.90 | grep \.[0-9]$ 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 I wouldn't. The documentation is fairly clear that the '%g' specifier is what gets used by default. If you want something else, you need to specify the format via the -f option; for example: $ seq -f %.2f 0.00 0.01 0.90| grep \.[0-9]0$ 0.00 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90 In any case, I think John's advice is wisest: don't use floating point math for iteration. These are exactly the sorts of troubles you get when doing so. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug or missing feature in who
Andreas Schwab wrote: [EMAIL PROTECTED] (Bob Proulx) writes: Alexander Schestag wrote: So, is there a way to tell who to list the users logged in via su as well? Not with who. AFAIK you would need to walk the process list for that information. There is really nothing special about a login process. It is just a normal process. Actually a login process is kind of special, because it creates a new session and becomes the leader of it. Changing the user with su, on the other hand, does not create a new session (use ps -ej to display the session id of every process). Still, it is the sole responsibility of the process creating the session to update the utmp/wtmp information. In other words, you cannot trust this information in any way. Not to mention that it's trivially easy to create a new session, and many programs do it as a matter of course (especially dæmons). The create new session syscall is generally used to disassociate from whatever terminal and process group it was running under, so it won't accidentally try to write to the terminal while it's in the background (STOPping it); and won't receive SIGHUP if that terminal goes away. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 6.9 and yes
James Youngman wrote: On 5/25/07, Eric Blake [EMAIL PROTECTED] wrote: 'yes' is not specified by any standards, so it is not portable to begin with. In the spirit of I'm going to replace you with a very small shell script... :) ( while :; do printf '%s\n' -v; done ) | head -n3 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: YYYYMMDD HHMMSS [TZ] ?
Karl Berry wrote: It already supports -MM-DD HH:MM:SS (also with TZ). I know, and I am glad, but as I wrote in my original message, the forms without punctuation would also be useful (to me anyway) to support. The punctuation is already optional: $ date -d 20070508\ 1406 Tue May 8 14:06:00 PDT 2007 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BKR01- problems detected with: chmod, xterm and linux-console
Eric Blake wrote: #$ echo - e \015\033[- 1Cxxx starts string xxx at position 0, ok Using \015 as the argument to echo is not portable shell; you should use \\015 or '\015' instead. Using -e isn't portable shell either, as POSIX requires echo to recognize no options, but instead treat them as arguments. printf would be a much more portable solution (still escaping or quoting backslashes, as Eric suggests). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uname
Dr. Douglas Lyon wrote: Hi All, uname does not work on the debian port to a mips based asus router... uname -p unknown but: uname -a Linux asus-debian 2.6.19.2 #9 Tue Apr 3 21:30:54 CEST 2007 mips GNU/Linux is correct. Actually, I'm getting the same behavior on my i686 Ubuntu 6.10.1 install. Note that the mips bit is probably the output from uname -m, not uname -p; uname -a lists print all information, in the following order, except omit -p and -i if unknown. Still, given that /proc/cpuinfo has useful info, perhaps -p shouldn't be unknown? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp/mv/dd to handle SIGXFSZ?
Philip Rowlands wrote: On Mon, 9 Apr 2007, Micah Cowan wrote: In the Ubuntu bugtracker, Malone, we've been getting several submissions of an issue, usually phrased along the lines of cp dumps core on copy of 4GB file to vfat (or usb), etc. See https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/75574 If the filesystem can't go any bigger, I wonder why the kernel generates a SIGXFSZ, rather than solely returning EFBIG? I assume there's no prevailing ulimit setting? Users report having this problem when they copy to (e.g.) vfat systems, but not ext3, so it seems to be FS-related. Even if it did turn out to be usage limit, I would think the problem would be the same: it's much more useful (IMO) to issue a diagnostic and attempt to proceed, than to coredump. :p As you will see in the comments of the bug whose link I gave above, I'm aware that this will break POSIX (which specifies default handling for signals in the various utils), but I feel the utility of handling this signal would outweigh the benefits of strict adherence to the standard (which of course, could be re-enabled via POSIXLY_CORRECT). My reading of the spec for signal.h is that implementation-defined abnormal termination actions, such as creation of a core file, may occur, so creating a core file isn't mandatory. I suspect implementation in this context refers to the whole [compliant] system, rather than any given process. Well, yes, but AIUI that's the implementation's definition of abnormal termination, and not of any particular single signal. In any case, core or no (which, after all, depends on the limit settings anyway), an abnormal termination /is/ mandated, which at least precludes further processing of other source files. :( (A user-friendly warning would still be permitted, though, as tools specified as having Default async event handling are allowed to handle and re-raise signals.) As a secondary note, some users are disgruntled that cp will go ahead and copy 4GB of data before it realizes there is a problem, and would prefer a preemptive check to see what the maximum file size is. There's no clue from statfs(2) as to the maximum valid filesize. An app could try to keep a mapping from the statfs.f_type field, but building and maintaining such a list of (*NIX personality, filesystem) pairs would be a lot of manual work. Yeah, that's pretty much what I figured. :/ -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp/mv/dd to handle SIGXFSZ?
Philip Rowlands wrote: On Mon, 9 Apr 2007, Micah Cowan wrote: Users report having this problem when they copy to (e.g.) vfat systems, but not ext3, so it seems to be FS-related. Even if it did turn out to be usage limit, I would think the problem would be the same: it's much more useful (IMO) to issue a diagnostic and attempt to proceed, than to coredump. :p I understand the problem, but I'm challenging the assumption that the Linux kernel is doing the right thing. If there's no RLIMIT_FSIZE restriction, why should the process be sent a SIGXFSZ? (I'm neither a kernel programmer or standards guru - I'd just like to see where this is documented.) Perhaps most POSIX systems behave this way... I'm afraid I don't have any others handy to check. You're right: I don't see any documentation on SIGXFSZ other than in the context of soft process limits; I had assumed, based on it's name and its implementation in reality (at least, in such drivers as vfat), that that was acceptable behavior. But I just found in write(): If a write() requests that more bytes be written than there is room for (for example, the process' file size limit or the physical end of a medium), only as many bytes as there is room for shall be written... [t]he next write of a non-zero number of bytes would give a failure return (except as noted below). Noted below includes generating SIGXFSZ for soft process limits, but says nothing about physical or file system limits; so it seems that write() /is/ in fact required to return EFBIG in this case. I'll go bug the kernel guys, then. :) Hey, if I had my way, there'd be no such abomination as SIGXFSZ. I think dumping core (or, for that matter, terminating at all) for a relatively normal error condition is a horrendous idea for default behavior. But now we're stuck with it... at least it seems that it's the kernel guys' problem: now the ulimited folks will just have to deal with it. :p Thanks for the help. -- Thanks, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
