Re: How to count the last line when it does not end with a newline character?
On Tue, 7 Sept 2021 at 11:35, Bernhard Voelker wrote: > On 9/5/21 07:37, Peng Yu wrote: > > I got 1 instead of 2 in the following example. How to count the last > > even when it does not end with a newline character? Thanks. > > > > $ printf 'a\nb'|wc -l > > 1 > > A text file (in contrast to a binary file) must end on a newline character, > otherwise the remainder after the last '\n' in the file is not an entire line. > > And that's what wc(1) effectively does (and says so in its man page): > > wc - print newline, word, and byte counts for each file > ___^^^_^^ > > If you'd like to treat the remainder as a line, then you have to add > a newline character at the end. > > $ printf 'a\nb\n' | wc -l > 2 Maybe it is worth to mention that the wc(1) is counting lines POSIX correctly. Number of the lines is number of valid lines, excluding incomplete lines. 3.206 Line A sequence of zero or more non- characters plus a terminating character. 3.195 Incomplete Line A sequence of one or more non- characters at the end of the file. Above definitions are from the web page below. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html -- Sami Kerola http://www.iki.fi/kerolasa/
Re: Wishing rmdir had a prompt
On Mon, 2 Sep 2019 at 05:50, Kaz Kylheku (Coreutils) <962-396-1...@kylheku.com> wrote: > > On 2019-09-01 17:50, Leslie S Satenstein via GNU coreutils General > Discussion wrote: > > rmdir -i > > I don't see this in a fairly recent GNU Coreutils 8.28 installation. > Must be very new? I think '-i, --interactive' was more of a proposal what option is needed than feedback how use command. Currently implemented options are below. http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/rmdir.c#n56 > There is some justification for such a thing. Though it may seem that > accidental > deletion of empty directories is easy to restore by recreating them, > that does not > put the file system back in the pre-deleted state. The modification > timestamps of > parent directories are tweaked, and new empty directories come up with > their own > modification timestamps as well as different inode numbers, permissions, > group and user > ownerships and such. There is no substitute to not deleting something; > what comes close > is recovering it from a backup. Unrelated to this request there's been times when I wish tar would have a way to 'extract' only meta-data, such as permissions and ownership, but not update file content. This would be handy when wanting to recover from accidental sudo chown -R /usr/ run or something of that sort. While on it being able to create tar file that contains only meta info would make permission revert quite interesting, and hopefully lightweight. But that is a totally new file format and miles away off topic what was requested originally. So let me add my two pennies to that discussion. > prompt me before removals I am not a maintainer, but I don't see any problem adding --interactive long only option. Getting a short option may clash with future posix requirement, so I believe they are not handed out without really good reasons. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: How to calculate date relative to another date?
On Tue, 21 May 2019 at 19:00, Peng Yu wrote: > For example, I want to calculate 5 years less a month from May 2018, > i.e., "2018/05", the result should be "2013/06". > > https://www.gnu.org/software/coreutils/manual/html_node/Examples-of-date.html > > I don't think the direct calculation of this kind of relative date is > possible with coreutiles' date command. Some kind of external > arithmetic calculation must be used. Is it so? Seems to work fine when date specification is not quite as ambiguous as "2018/05". $ date --iso --date='2018-05-01 5 years ago' 2013-05-01 -- Sami Kerola http://www.iki.fi/kerolasa/
Re: [PATCH] id: add feature to accept multiple usernames
On 15 July 2018 at 19:15, Pádraig Brady wrote: > An alternative would be to output '\n' in that case > which wouldn't be as general, but would be easier to parse > with existing tools. Or have you considered using lslogins from util-linux? It gives a lot of control what to print and how. lslogins --logins=$USER,nobody --output=USER,GROUP,SUPP-GROUPS -- Sami Kerola http://www.iki.fi/kerolasa/
Re: rm feature: don't attempt to remove the same file twice
On 1 September 2016 at 16:39, Ed Avis <e...@waniasset.com> wrote: > In fact, 'rm -f a a' still does twice the filesystem operations. > It still calls newfstatat(AT_FDCWD, "a", ...) twice and unlinkat(AT_FDCWD, > "a", 0) twice, on my system. > > What I am suggesting is to check for the same filename string having been > seen before and avoid touching the filesystem. > This is a small user-friendliness improvement in the mode without -f, since > "warning: file 'a' specified twice" is easier to understand > than "cannot remove 'a': No such file or directory", but it is also a > performance improvement. > Pretty marginal I admit, except perhaps for a network filesystem hosted by a > server on the other side of the planet. This looks valid to me rm a a there could be other process, such as touch a a running parallel. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: [PATCH] Speedup wc -l
On 15 March 2015 at 22:18, Pádraig Brady p...@draigbrady.com wrote: On 15/03/15 21:14, Kristoffer Brånemyr wrote: Den söndag, 15 mars 2015 20:13 skrev Pádraig Brady p...@draigbrady.com: On 15/03/15 08:33, Kristoffer Brånemyr wrote: Hi, I did some tests and found out you can actually beat memchr with a simple loop. Tests were done on a Intel Xeon E3-1231v3 (4*3.4GHz), on a 4GB file that was already cached in memory. Benchmarking was done simply with the 'time' command. I don't know how this code would run on other architectures, but I guess you could put it in an #ifdef? Coreutils 2.83 version, compiled with -O3: 507755520 /home/ztion/words real0m3.126s user0m2.699s sys0m0.429s Improved version compiled with -O2: 507755520 /home/ztion/words real0m2.857s user0m2.461s sys0m0.396s Improved version compiled with -O3: 507755520 /home/ztion/words real0m1.518s user0m1.157s sys0m0.361s I studied the generated assembly and with -O3 gcc generates some fancy SSE code, getting some nice speedups. memchr is also SSE optimized as far as I know, so it's interesting that this is so much faster, twice as fast actually. In case you don't like turning -O3 on for some reason (the default in coreutils is -O2 i think), the best version I could put together for -O2 was this: Improved version 2, compiled with -O2: 507755520 /home/ztion/words real0m2.206s user0m1.827s sys0m0.379s Interesting. Thanks for the results. I use 'gcc -march=native -g -O3' locally, and with that can't see a difference in performance. What version of glibc and gcc are you using? gcc-4.9.2-1.fc21.x86_64 and glibc-2.20-7.fc21.x86_64 here. thanks, Pádraig. Hi, This is with gcc 4.9.2-7 and glibc 2.19-17 on Debian amd64. The difference is still there for me when compiling with your CFLAGS. Have they improved memchr in glibc 2.20? I don't think they have that yet in debian unfortunately. What cpu do you have? i3-2310M I was doing a very quick test with _short_ lines Specifically /usr/share/dict/words Note GCC should be using builtin_memchr here so not hitting the function call overhead. I'll look in more detail later. Build from coreutils gnulib git checkouts from point v8.23-149-gd95cdcc real0m0.824s real0m0.828s real0m0.830s real0m0.831s real0m0.875s After Kristoffer's change real0m0.774s real0m0.776s real0m0.778s real0m0.779s real0m0.780s I'm using up to date testing archlinux. $ pacman -Q gcc glibc linux gcc 4.9.2-4 glibc 2.21-2 linux 3.19.1-1 Built with: gcc -O3 -Ofast CPU: AMD E1-1200 Reference. My test input had following data: $ time wc test-input 1141570 8211600 49489140 test-input -- Sami Kerola http://www.iki.fi/kerolasa/
Re: cloning to multiple drives with the dd command.
On 20 February 2015 at 09:47, Mike Hodson myst...@gmail.com wrote: Hello Didier et al, On Fri, Feb 20, 2015 at 12:55 AM, didier chavaroche didier.chavaro...@distri-service.com wrote: The way I use the dd command is the following: I developped a JAVA application which in a thread class call a script with two arguments SOURCE TARGET. In this script I use the command sudo dd if=SOURCE of=TARGET bs=4096 conv=notrunc,noerror Then the script identify the PID of the dd command and send every 5 seconds the -USR1 signal throught kill to print out the progress. This indeed sounds like concurrent processes, definitely more complex and involved than the simple 'dd ' and repeat 22 times more, but the same I/O activity should take place, regardless. The artifical 'wall' you seemed to hit, around 11 or so processes; while I can't provide proof, perhaps you can look into this as a possibility if you are so inclined: I think it is disk cache even allowing you to reach 100 in the first place. I can't help but thinking that if your processes aren't exactly lock-step matched in input vs output, you will likely have 1 task that starts streaming the file, and populating the file into your system's disk cache. The rest of X amount of processes will start writing to the outputs and potentially slow down / become bogged down / not be requesting the same bytes that already exist in disk cache, by about the time the 12th process starts.. At which point, the disk is now thrashing, and the cache is having a very bad day... I would be _very_ interested to know if this same behavior occurs if you have your source file in a ramdisk. Is there a reason why $ dd if=/dev/zero count=1 of=/tmp/a of=/tmp/b could not be made to write to two, or any number of of= destinations, in single execution? -- Sami Kerola http://www.iki.fi/kerolasa/
Re: [PATCH] rename: move command from util-linux to coreutils
On 24 December 2013 22:29, Sami Kerola kerol...@iki.fi wrote: This is a resubmission[1][2] of the rename(1), with attempt to move it from util-linux package to coreutils. Various compiler warnings are removed, make syntax-check passes, --test option is renamed to --dry-run, file list can be wrote to stdin but only if --files0-from is in use. AFAIK most of the issues mentioned earlier are sorted, and it is either time to get more advice what could be improved, or final reject for the proposal to move the command to this project. [1] http://lists.gnu.org/archive/html/coreutils/2012-06/threads.html#00021 [2] http://lists.gnu.org/archive/html/coreutils/2012-07/threads.html#00014 Hello coreutils maintainer(s), It's been a while since change submission, and I guess no review is the same thing as final reject. Getting a formal confirmation reject would be good to avoid any uncertainty which project hosts the code of the rename(1). -- Sami Kerola http://www.iki.fi/kerolasa/
Re: [PATCH] maint: make ChangeLog generation more robust
On 3 May 2014 17:38, Jim Meyering j...@meyering.net wrote: On Sat, Apr 19, 2014 at 8:08 AM, Jim Meyering j...@meyering.net wrote: On Sat, Apr 19, 2014 at 4:51 AM, Pádraig Brady p...@draigbrady.com wrote: * Makefile.am (gen-ChangeLog): Sync changes from GNU hello to, ensure exit status is propagated and to support an optional git-log-fix file. Hi PádPádraigraig, Thank you for repairing that. Your change looks fine. I missed something in that review. Sorry. Here's a patch. I'll push this to hello as well, upon ack. Hi Pádraig and Jim, The patch Jim sent looked good so I pushed it to GNU Hello upstream. Thanks. -- Sami Kerola http://www.iki.fi/kerolasa/
[PATCH] rename: move command from util-linux to coreutils
The implementation is completely rewrote without chaning existing command line syntax. This implementation adds --exec option, which will allow use of a string manipulation command, such as 'tr' or 'sed' to determine target names or rename operations. * AUTHORS: Add my name. * NEWS: Mention the new program. * README: Reference the new program. * build-aux/gen-lists-of-programs.sh: Update. * doc/coreutils.texi: Document the new command. * man/.gitignore: Ignore the new man page. * man/local.mk: Reference the new man page. * man/rename.x: A new template. * po/POTFILES.in: Add new c file. * scripts/git-hooks/commit-msg: Allow rename: commit prefix. * src/.gitignore: Ignore the new binary. * src/local.mk: Reference the new command. * src/rename.c: New file. * tests/local.mk: Reference the new tests. * tests/misc/rename-exec: Test new command exec option. * tests/misc/rename-foobar: Basic test for the new command. --- AUTHORS| 1 + NEWS | 5 + README | 8 +- build-aux/gen-lists-of-programs.sh | 1 + doc/coreutils.texi | 117 ++- man/.gitignore | 1 + man/local.mk | 1 + man/rename.x | 10 + po/POTFILES.in | 1 + scripts/git-hooks/commit-msg | 13 +- src/.gitignore | 1 + src/local.mk | 3 + src/rename.c | 659 + tests/local.mk | 2 + tests/misc/rename-exec.sh | 30 ++ tests/misc/rename-foo2bar.sh | 30 ++ 16 files changed, 872 insertions(+), 11 deletions(-) create mode 100644 man/rename.x create mode 100644 src/rename.c create mode 100755 tests/misc/rename-exec.sh create mode 100755 tests/misc/rename-foo2bar.sh diff --git a/AUTHORS b/AUTHORS index df21e90..e2ae037 100644 --- a/AUTHORS +++ b/AUTHORS @@ -64,6 +64,7 @@ ptx: François Pinard pwd: Jim Meyering readlink: Dmitry V. Levin realpath: Pádraig Brady +rename: Sami Kerola rm: Paul Rubin, David MacKenzie, Richard M. Stallman, Jim Meyering rmdir: David MacKenzie runcon: Russell Coker diff --git a/NEWS b/NEWS index cbac480..212b697 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,11 @@ GNU coreutils NEWS-*- outline -*- * Noteworthy changes in release ?.? (-??-??) [?] +** New programs + + rename: Rename multiple files using a pattern. This command will replace + an utility with same name in util-linux package. + * Noteworthy changes in release 8.22 (2013-12-13) [stable] diff --git a/README b/README index b81897e..4f65819 100644 --- a/README +++ b/README @@ -12,10 +12,10 @@ The programs that can be built with this package are: factor false fmt fold groups head hostid hostname id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink - realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum - shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test - timeout touch tr true truncate tsort tty uname unexpand uniq unlink - uptime users vdir wc who whoami yes + realpath rename rm rmdir runcon seq sha1sum sha224sum sha256sum + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum + sync tac tail tee test timeout touch tr true truncate tsort tty uname + unexpand uniq unlink uptime users vdir wc who whoami yes See the file NEWS for a list of major changes in the current release. diff --git a/build-aux/gen-lists-of-programs.sh b/build-aux/gen-lists-of-programs.sh index bf63ee3..2962a82 100755 --- a/build-aux/gen-lists-of-programs.sh +++ b/build-aux/gen-lists-of-programs.sh @@ -96,6 +96,7 @@ normal_progs=' pwd readlink realpath +rename rm rmdir runcon diff --git a/doc/coreutils.texi b/doc/coreutils.texi index 9c2b79c..27a3602 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -96,6 +96,7 @@ * pwd: (coreutils)pwd invocation. Print working directory. * readlink: (coreutils)readlink invocation. Print referent of a symlink. * realpath: (coreutils)readpath invocation. Print resolved file names. +* rename: (coreutils)rename invocation. Rename multiple files. * rm: (coreutils)rm invocation. Remove files. * rmdir: (coreutils)rmdir invocation. Remove empty directories. * runcon: (coreutils)runcon invocation. Run in specified SELinux CTX. @@ -195,7 +196,7 @@ Free Documentation License''. * Printing text::echo printf yes * Conditions:: false true test expr * Redirection:: tee -* File name manipulation:: dirname basename pathchk mktemp realpath +* File name manipulation:: dirname basename pathchk rename mktemp realpath
Re: [PATCH] rename: move command from util-linux to coreutils
Seasons greetings, This is a resubmission[1][2] of the rename(1), with attempt to move it from util-linux package to coreutils. Various compiler warnings are removed, make syntax-check passes, --test option is renamed to --dry-run, file list can be wrote to stdin but only if --files0-from is in use. AFAIK most of the issues mentioned earlier are sorted, and it is either time to get more advice what could be improved, or final reject for the proposal to move the command to this project. [1] http://lists.gnu.org/archive/html/coreutils/2012-06/threads.html#00021 [2] http://lists.gnu.org/archive/html/coreutils/2012-07/threads.html#00014 On 24 December 2013 22:28, Sami Kerola kerol...@iki.fi wrote: The implementation is completely rewrote without chaning existing command line syntax. This implementation adds --exec option, which will allow use of a string manipulation command, such as 'tr' or 'sed' to determine target names or rename operations. * AUTHORS: Add my name. * NEWS: Mention the new program. * README: Reference the new program. * build-aux/gen-lists-of-programs.sh: Update. * doc/coreutils.texi: Document the new command. * man/.gitignore: Ignore the new man page. * man/local.mk: Reference the new man page. * man/rename.x: A new template. * po/POTFILES.in: Add new c file. * scripts/git-hooks/commit-msg: Allow rename: commit prefix. * src/.gitignore: Ignore the new binary. * src/local.mk: Reference the new command. * src/rename.c: New file. * tests/local.mk: Reference the new tests. * tests/misc/rename-exec: Test new command exec option. * tests/misc/rename-foobar: Basic test for the new command. --- AUTHORS| 1 + NEWS | 5 + README | 8 +- build-aux/gen-lists-of-programs.sh | 1 + doc/coreutils.texi | 117 ++- man/.gitignore | 1 + man/local.mk | 1 + man/rename.x | 10 + po/POTFILES.in | 1 + scripts/git-hooks/commit-msg | 13 +- src/.gitignore | 1 + src/local.mk | 3 + src/rename.c | 659 + tests/local.mk | 2 + tests/misc/rename-exec.sh | 30 ++ tests/misc/rename-foo2bar.sh | 30 ++ 16 files changed, 872 insertions(+), 11 deletions(-) create mode 100644 man/rename.x create mode 100644 src/rename.c create mode 100755 tests/misc/rename-exec.sh create mode 100755 tests/misc/rename-foo2bar.sh diff --git a/AUTHORS b/AUTHORS index df21e90..e2ae037 100644 --- a/AUTHORS +++ b/AUTHORS @@ -64,6 +64,7 @@ ptx: François Pinard pwd: Jim Meyering readlink: Dmitry V. Levin realpath: Pádraig Brady +rename: Sami Kerola rm: Paul Rubin, David MacKenzie, Richard M. Stallman, Jim Meyering rmdir: David MacKenzie runcon: Russell Coker diff --git a/NEWS b/NEWS index cbac480..212b697 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,11 @@ GNU coreutils NEWS-*- outline -*- * Noteworthy changes in release ?.? (-??-??) [?] +** New programs + + rename: Rename multiple files using a pattern. This command will replace + an utility with same name in util-linux package. + * Noteworthy changes in release 8.22 (2013-12-13) [stable] diff --git a/README b/README index b81897e..4f65819 100644 --- a/README +++ b/README @@ -12,10 +12,10 @@ The programs that can be built with this package are: factor false fmt fold groups head hostid hostname id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink - realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum - shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test - timeout touch tr true truncate tsort tty uname unexpand uniq unlink - uptime users vdir wc who whoami yes + realpath rename rm rmdir runcon seq sha1sum sha224sum sha256sum + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum + sync tac tail tee test timeout touch tr true truncate tsort tty uname + unexpand uniq unlink uptime users vdir wc who whoami yes See the file NEWS for a list of major changes in the current release. diff --git a/build-aux/gen-lists-of-programs.sh b/build-aux/gen-lists-of-programs.sh index bf63ee3..2962a82 100755 --- a/build-aux/gen-lists-of-programs.sh +++ b/build-aux/gen-lists-of-programs.sh @@ -96,6 +96,7 @@ normal_progs=' pwd readlink realpath +rename rm rmdir runcon diff --git a/doc/coreutils.texi b/doc/coreutils.texi index 9c2b79c..27a3602 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -96,6 +96,7 @@ * pwd: (coreutils)pwd invocation. Print working
Re: RFE: Modification to the Timezone Modifier
On 10 December 2013 12:35, Marko Myllynen mylly...@redhat.com wrote: On 2013-12-10 02:49, Eric Blake wrote: On 12/09/2013 08:22 AM, Marko Myllynen wrote: It seems like it would be reasonable to add some sort of modifier to the existing %:::z to request suppression of leading 0. If we didn't have back-compat to worry about, I'd even suggest making %:::z be the short form, and %0:::z be the 0-padded form. sorry for the delayed reply and thanks for your insights - I've now filed http://austingroupbugs.net/view.php?id=772 so let's see how it goes. the request has been rejected on the basis that there are no current implementations. The rejection also mentioned that an appropriate setting of TZ can already be used to achieve what you want: TZ=UTC+3+3UTC+4 date In other words, if setting TZ is already sufficient, then why standardize anything else? sorry, I think I was being a bit unclear earlier - I used date as an example but the goal was to be able to adjust the fi_FI locale so that it would produce correct time strings. I've added this clarification to the above request as well. Hi Marko, I wonder would it be easier to ask Finnish localization recommendation group to reconsider the format, with emphasis they should choose something that is already supported. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: Formatting Columnar/Delimited Data?
On 16 September 2013 15:43, Aaron Davies adavie...@me.com wrote: Are there any tools for formatting character-delimited, columnar files (csv, tab-separated, etc.) for easy viewing? I'm looking for something that will work out the proper width for each column and use that to output the file in space-padded, fixed-width format. A command from util-linux package might suitable for purpose you are after. column -s, -t example.csv -- Sami Kerola http://www.iki.fi/kerolasa/
factor and large prime numbers
Hello, I were curious how quickly factor will process prime numbers, and found something rather strange. For example these five can be computed quite quickly. time factor 10333147966386144929513375231 time factor 3719933267899012174679994481508351 time factor 137637530912263450463159795815809023 time factor 523022617466607600072241000742911 time factor 203978820811974433586402817399028973567 But much smaller numbers will take ages to give results (to be honest I gave up). time factor 868331761881188649551819440127999 time factor 29523279903960414084761860964351999 Any idea what is going on? -- Sami Kerola http://www.iki.fi/kerolasa/
Re: factor and large prime numbers
On 22 July 2013 16:01, Sami Kerola kerol...@iki.fi wrote: I were curious how quickly factor will process prime numbers, and found something rather strange. For example these five can be computed quite quickly. time factor 10333147966386144929513375231 time factor 3719933267899012174679994481508351 time factor 137637530912263450463159795815809023 time factor 523022617466607600072241000742911 time factor 203978820811974433586402817399028973567 Opps. A silly mistake. Not only one of the above is prime. time factor 523022617466607600072241000742911 But that hardly changes the strangeness... But much smaller numbers will take ages to give results (to be honest I gave up). time factor 868331761881188649551819440127999 time factor 29523279903960414084761860964351999 Any idea what is going on? ...smaller primes can be a lot slower to factor than greater. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: [PATCH] ls: do not print directory indicator for root
On 13 May 2013 00:24, Bob Proulx b...@proulx.com wrote: Pádraig Brady wrote: Thanks for the patch, however I still think it adds inconsistency for little gain. Creating this inconsistency also feels wrong to me too. It just doesn't seem right that everything else is implemented consistently but this one case is made special. In effect making this case inconsistent with the others. It was mentioned that a trailing / is confusing and could be mistaken for a separate // root indicator. Though consider: $ /bin/ls -Fd --color // /// That demonstrates the already possible ambiguity in root indicators. More importantly though, the trailing / has a different color to that of the specified path, which in the normal case should avoid ambiguity? Agreed. Also consider this case: (With the color indicated for email. Probably better if you run the command yourself.) $ env ls -Fdlog --color / /var /var/tmp drwxr-xr-x 25 4096 May 8 23:29 blue//blue/ drwxr-xr-x 14 4096 Aug 29 2011 blue/var/blue/ drwxrwxrwt 3 20480 May 12 16:04 blue/var/tmp/blue/ It doesn't seem right that it would ever display this way: $ env ls -Fdlog --color / /var /var/tmp drwxr-xr-x 25 4096 May 8 23:29 blue//blue drwxr-xr-x 14 4096 Aug 29 2011 blue/var/blue/ drwxrwxrwt 3 20480 May 12 16:04 blue/var/tmp/blue/ That just seems wrong to me. Why would that one be different. Also I'm not sure about treating root specially here. This generally is when any directory is specified with trailing / $ /bin/ls -dF --color ~/ /home/padraig// Another good example. Again color and context should avoid any ambiguity? I would say * consistency *, color and context. With emphasis on consistency. Hi Bob and Pádraig, The --color consistency seems to be so good argument against approving the patch that I cannot defend it. IMHO it the change belongs to rejected area with reference to this thread. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: Adding progress bar feature to cp and mv commands
On 12 May 2013 04:30, Lokesh Walase flokesh...@gmail.com wrote: I am interested in adding progress bar feature to cp and mv commands. For this I downloaded the latest source code GNU-coreutils-8.21. I have fair knowledge of C and can understand the code. However the code is too big and I m right now confused as to what to do or where to start from, or what should I read and which part of code I should focus. Is this too ambitious to start with ? Kindly guide me. Hi Lokesh, I am not a maintainer, but I would find it surprising if progress bar would be accepted this time. http://lists.gnu.org/archive/html/bug-coreutils/2007-12/msg00120.html http://lists.gnu.org/archive/html/coreutils/2010-09/msg00052.html http://lists.gnu.org/archive/html/coreutils/2011-08/msg00015.html But perhaps something could be done with the proposal. Would it make sense to add 'rejected feature requests' section to http://www.pixelbeat.org/patches/coreutils/inbox_apr_2013.html and have a link to latest summary in README.hacking? IMHO the rejected section should contain only features which has already been discussed couple times, such as the progress bar in cp or mv. -- Sami Kerola http://www.iki.fi/kerolasa/
ls: directory indication, again
Hi all, It is about time revisit the unfinished 'ls -Fd /' patch which was discussed couple months ago. http://lists.gnu.org/archive/html/coreutils/2013-02/msg00161.html The is_root() now uses libc code, which is shorter and faster, as pointed out by Eric earlier. I thought a test might be appriciated, so I included one. Hopefully this time around the change can be pushed either to upstream or wall of rejection. -- Sami Kerola http://www.iki.fi/kerolasa/
[PATCH] ls: do not print directory indicator for root
Previously 'ls -Fd /' printed unnecessary directory indicator. The root
is represented by '/' character, which does not need to be repeated.
* src/ls.c: (print_long_format, print_file_name_and_frills): Check if a
output name is root, and skip indicator when necessary.
* src/ls.c: A new function is_root().
* tests/local.mk: Add ts/ls/root-slash.sh.
* tests/ls/root-slash.sh: New file.
---
src/ls.c | 12 ++--
tests/local.mk | 1 +
tests/ls/root-slash.sh | 31 +++
3 files changed, 42 insertions(+), 2 deletions(-)
create mode 100755 tests/ls/root-slash.sh
diff --git a/src/ls.c b/src/ls.c
index d9876f8..74e038e 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -250,6 +250,7 @@ static uintmax_t gobble_file (char const *name, enum
filetype type,
static bool print_color_indicator (const struct fileinfo *f,
bool symlink_target);
static void put_indicator (const struct bin_str *ind);
+static bool is_root(const char *path);
static void add_ignore_pattern (const char *pattern);
static void attach (char *dest, const char *dirname, const char *name);
static void clear_files (void);
@@ -3970,7 +3971,7 @@ print_long_format (const struct fileinfo *f)
print_type_indicator (true, f-linkmode, unknown);
}
}
- else if (indicator_style != none)
+ else if (indicator_style != none !is_root(f-name))
print_type_indicator (f-stat_ok, f-stat.st_mode, f-filetype);
}
@@ -4212,7 +4213,7 @@ print_file_name_and_frills (const struct fileinfo *f,
size_t start_col)
size_t width = print_name_with_quoting (f, false, NULL, start_col);
- if (indicator_style != none)
+ if (indicator_style != none !is_root(f-name))
width += print_type_indicator (f-stat_ok, f-stat.st_mode, f-filetype);
return width;
@@ -4397,6 +4398,13 @@ put_indicator (const struct bin_str *ind)
fwrite (ind-string, ind-len, 1, stdout);
}
+/* Find out if the path is root. */
+static bool _GL_ATTRIBUTE_PURE
+is_root (const char *path)
+{
+ return path[strspn(path, /)] == '\0';
+}
+
static size_t
length_of_file_name_and_frills (const struct fileinfo *f)
{
diff --git a/tests/local.mk b/tests/local.mk
index 5ec7d98..1f3fd70 100644
--- a/tests/local.mk
+++ b/tests/local.mk
@@ -542,6 +542,7 @@ all_tests = \
tests/ls/readdir-mountpoint-inode.sh \
tests/ls/recursive.sh\
tests/ls/root-rel-symlink-color.sh \
+ tests/ls/root-slash.sh \
tests/ls/rt-1.sh \
tests/ls/slink-acl.sh\
tests/ls/stat-dtype.sh \
diff --git a/tests/ls/root-slash.sh b/tests/ls/root-slash.sh
new file mode 100755
index 000..6646322
--- /dev/null
+++ b/tests/ls/root-slash.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+# check -F or -p will not add extra slashes to root
+
+# Copyright (C) 2013 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+. ${srcdir=.}/tests/init.sh; path_prepend_ ./src
+print_ver_ ls
+
+LC_MESSAGES=C ls -pd / out || fail=1
+LC_MESSAGES=C ls -Fd / out || fail=1
+cat EOF exp
+/
+/
+EOF
+
+compare exp out || fail=1
+
+Exit $fail
--
1.8.2.3
Re: ls and root directory indicator
On Mon, Feb 25, 2013 at 1:27 PM, Eric Blake ebl...@redhat.com wrote:
On 02/24/2013 11:09 AM, Pádraig Brady wrote:
On 02/24/2013 05:39 PM, Sami Kerola wrote:
Hello,
When using file type indicator to a root, e.g.,
$ ls -Fd /
//
two slashes are printed. To me that feels wrong. Patch below is an
attempt to make root print out to be a single slash. Perhaps there is
more elegant way to do the same. Or maybe I am mistaking, and double
slash is correct, although I could not find earlier posting about
that.
I agree it looks a bit awkward, but I think it's more consistent
to keep the trailing /. Consider a script that filters on and
strips a trailing /
I kind of like the idea of omitting the trailing slash for roots (note
the plural); since '/' and '//' are not necessarily the same root, and
listing '//' for '/' or '///' for '//' is confusing. However, since the
proposed patch does not special case '//', it is not an appropriate
patch in its current form.
Hi Eric,
Did I understood correctly that a patch such below would be more preferred?
Secondly,pardon my ignorance, I thought '/' and '//' or how ever many
slashes are the same root. Is this some non-obvious portability
gotcha? A link to education material would be great.
From 745f1782cf02e8241487f26e6b08cc30cd8fbdb5 Mon Sep 17 00:00:00 2001
From: Sami Kerola kerol...@iki.fi
Date: Sun, 24 Feb 2013 17:17:20 +
Subject: [PATCH] ls: do not print directory indicator for root
Organization: Lastminute.com
Previously 'ls -Fd /' printed unnecessary directory indicator. The root
is represented by '/' character, which does not need to be repeated.
* src/ls.c: (print_long_format, print_file_name_and_frills): Check if a
output name is root, and skip indicator when necessary.
* src/ls.c: A new function is_root_only().
---
src/ls.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/ls.c b/src/ls.c
index d9876f8..70fbd23 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -250,6 +250,7 @@ static uintmax_t gobble_file (char const *name,
enum filetype type,
static bool print_color_indicator (const struct fileinfo *f,
bool symlink_target);
static void put_indicator (const struct bin_str *ind);
+static int is_root_only(const char *path);
static void add_ignore_pattern (const char *pattern);
static void attach (char *dest, const char *dirname, const char *name);
static void clear_files (void);
@@ -3970,7 +3971,7 @@ print_long_format (const struct fileinfo *f)
print_type_indicator (true, f-linkmode, unknown);
}
}
- else if (indicator_style != none)
+ else if (indicator_style != none is_root_only(f-name))
print_type_indicator (f-stat_ok, f-stat.st_mode, f-filetype);
}
@@ -4212,7 +4213,7 @@ print_file_name_and_frills (const struct
fileinfo *f, size_t start_col)
size_t width = print_name_with_quoting (f, false, NULL, start_col);
- if (indicator_style != none)
+ if (indicator_style != none is_root_only(f-name))
width += print_type_indicator (f-stat_ok, f-stat.st_mode, f-filetype);
return width;
@@ -4397,6 +4398,21 @@ put_indicator (const struct bin_str *ind)
fwrite (ind-string, ind-len, 1, stdout);
}
+/* Find out if the output name is root, and represent it as a single
+ * slash even if file type indication is requested. */
+static int _GL_ATTRIBUTE_PURE
+is_root_only (const char *path)
+{
+ while (*path)
+{
+ if (*path == '/')
+path++;
+ else
+return 1;
+}
+ return 0;
+}
+
static size_t
length_of_file_name_and_frills (const struct fileinfo *f)
{
--
1.8.1.4
ls and root directory indicator
Hello, When using file type indicator to a root, e.g., $ ls -Fd / // two slashes are printed. To me that feels wrong. Patch below is an attempt to make root print out to be a single slash. Perhaps there is more elegant way to do the same. Or maybe I am mistaking, and double slash is correct, although I could not find earlier posting about that. From 639409e3355676cb786a403eea60c1ef4bbaf61d Mon Sep 17 00:00:00 2001 From: Sami Kerola kerol...@iki.fi Date: Sun, 24 Feb 2013 17:17:20 + Subject: [PATCH] ls: do not print directory indicator for root Organization: Lastminute.com Previously 'ls -Fd /' printed unnecessary directory indicator. The root is represented by '/' character, which does not need to be repeated. * src/ls.c: (print_long_format, print_file_name_and_frills): Check if a output name is root, and skip indicator when necessary. --- src/ls.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/ls.c b/src/ls.c index d9876f8..a8d02d2 100644 --- a/src/ls.c +++ b/src/ls.c @@ -3970,7 +3970,7 @@ print_long_format (const struct fileinfo *f) print_type_indicator (true, f-linkmode, unknown); } } - else if (indicator_style != none) + else if (indicator_style != none strcmp(f-name, /)) print_type_indicator (f-stat_ok, f-stat.st_mode, f-filetype); } @@ -4212,7 +4212,7 @@ print_file_name_and_frills (const struct fileinfo *f, size_t start_col) size_t width = print_name_with_quoting (f, false, NULL, start_col); - if (indicator_style != none) + if (indicator_style != none strcmp(f-name, /)) width += print_type_indicator (f-stat_ok, f-stat.st_mode, f-filetype); return width; -- 1.8.1.4
Re: [PATCH] Support for --size in du
On Sun, Jan 20, 2013 at 10:55 AM, Pádraig Brady p...@draigbrady.com wrote:
On 01/19/2013 10:47 PM, Bernhard Voelker wrote:
On 01/17/2013 03:58 PM, Pádraig Brady wrote:
I Just noticed another option from BSD:
-t threshold
Display only entries for which size exceeds threshold. If
threshold is negative, display only entries for which size is
less than the absolute value of threshold.
I slightly prefer --min-size and --max-size,
though not at the expense of losing the opportunity
to increase compat between these tools.
I suppose we could rename --size to --threshold too.
It seems there are many ways - like always. ;-)
I think --min-size/--max-size has a functional plus over one
single new option. But increasing compatibility to BSD is tempting.
If I'd be asked to decide between --size and --threshold then
the latter is the winner: a) BSD compat, b) the abbreviation
of the option better fits into the already existing ones,
see --size vs. --si, while --th is (currently) fine.
I'll change the patch towards --threshold then. WDYT?
+1
I don't think adding extra --{min,max}-size options are worth it.
My 2 pennies, might be off/new topic.
I am often looking for greatest N files/directories in size. For
instance when partition is nearly full then the line I write is
du -max /var/ | sort -n | tail -10
In my fantasy world there would be new long only option in du doing the same.
du -hax --top=10 # the 10 could be default when optional option is not defined.
That would answer to the question I often have in mind; what is
filling the disk?
I am not sure would I ever remember to use --min-size --max-size du
options. The find command does excellent job for that purpose, and
it's burned into at least to my memory as a utility to do that job.
Another drawback with --max-size is that when I am interested what is
filling disk I need to guess a limit. If I get it wrong the listing is
either very long or nothing, and rerun is required. The guess
iteration loop can be avoided if --top is present.
--
Sami Kerola
http://www.iki.fi/kerolasa/
Re: rename: move command from util-linux to coreutils
On Tue, Jul 17, 2012 at 10:07 PM, Jim Meyering j...@meyering.net wrote: Erik Auerswald wrote: On 07/17/2012 05:10 PM, Sami Kerola wrote: On Mon, Jul 9, 2012 at 3:27 PM, Jim Meyeringj...@meyering.net wrote: [...] A few things should be changed regardless. For consistency with other GNU tools: s/--test/--dry-run/ I changed the option to '-u, --dry-run' which is exact match with mktemp. I don't like the short option '-u'. On debian, the PERL rename (/usr/bin/prename, see update-alternatives --list rename) uses the short option '-n' for dry-run functionality. Not sure about other rename programs. I'd prefer just the long option '--dry-run'. I agree. Using no short option is probably best, especially when you realize that you can abbreviate it as --d (assuming there's no other --d... option). However, if you feel a short-named option is required, then -n is more standard. For example, GNU make and numerous git commands provide -n as a synonym for --dry-run. I removed the short option. As it has said many times in the list they are easier to add than remove. If the short option is needed in future it surely will be added. -- Sami Kerola http://www.iki.fi/kerolasa/
Re: rename: move command from util-linux to coreutils
On Mon, Jul 9, 2012 at 3:27 PM, Jim Meyering j...@meyering.net wrote: Hi Jim, Thanks for the fixes. You're welcome. There is too much new and untested code to include this new program in the upcoming release. That is ok. Perhaps coreutils 8.19 or 8.20 is suitable release target for this command. A few things should be changed regardless. For consistency with other GNU tools: s/--test/--dry-run/ I changed the option to '-u, --dry-run' which is exact match with mktemp. Also, please ensure that your new code compiles when configure with --enable-gcc-warnings. All errors and warnings are fixed. Thank you for mentioning the --enable-gcc-warnings, I missed it in README.hacking. The patch is also moved on top of upstream HEAD. As I do not expect the patch to be either rejected or accepted any time soon I probably will have to do the same few times more, which is not a problem other than you will see forced pushes on my side. The following changes since commit 2f90a1b19161d4924c251dce9cf5ff8a6d4c1d13: maint: move two df tests from tests/misc to tests/df (2012-07-16 02:51:41 +0100) are available in the git repository at: git://github.com/kerolasa/coreutils.git rename -- Sami Kerola http://www.iki.fi/kerolasa/
Re: rename command
On Tue, Jun 28, 2011 at 23:37, James Youngman j...@gnu.org wrote: If we're going to implement a rename command, can we make one that copes with internal newlines (IIRC rename does not) and doesn't force the user to assume path names are text[1]? [1] UNIX-like kernels mostly think path names are byte sequences terminated by '\0', possibly including one or more instances of '/'. In particular, filesystems routinely contain files with a multiplicity of character encodings. Sounds reasonable. After hearing what you and others has said I made couple modifications to the command. o Support recursion. o Support input from stdin, and have a switch for null terminated names. That will allow find -print0 | rename combination to rock. o Add upper lower casing options, which needs to obey locale. o Add --test option. If this option is really wanted I need assistance how to make test work properly. The current copy.h flags does not support test and I feel reluctant to add such. Secondly this is not even that simple. With --sed one can do such wacky renames that expressing how the situation will look like after a run might be very difficult. o Add --sed to do complicated name manipulations (only an idea). Assuming this is desired should I simply copy all necessary code from sed to be a coreutils/src/sed_functions.c? Perhaps sed style string manipulations should be part of gnulib. Perhaps something other, better and maintainer acceptable? See bellow snapshot of a usage output after latest modifications. Same can be found in rough and functionally broken patch attachment. -- snip $ ./rename --help Usage: ./rename [OPTION]... EXPRESSION REPLACEMENT FILE... or: ./rename [OPTION]... FILE... or: ./rename [OPTION]... Rename lots of files in directory. --files0-from=FILE read rename entries from NUL-terminated file -r, -R, --recursive rename in directories recursively -D, --dereference-args dereference only symlinks that are listed on the command line -L, --dereference dereference all symbolic links -x, --one-file-system skip directories on different file systems --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument -S, --suffix=SUFFIX override the usual backup suffix -f, --force do not prompt before overwriting -i, --interactive prompt before overwrite -n, --no-clobberdo not overwrite an existing file If you specify more than one of -f, -i, -n, only the final one takes effect. --sed=s/regexp/replacement/ use sed regular expression replace syntax FIXME -u, --uppercase upper case the names FIXME -l, --lowercase lower case the names FIXME -t, --test show a dry-run print out FIXME -v, --verbose explain what is being done --help display this help and exit --version output version information and exit -- snip p.s. I will away keyboard for next week so finalization of the command needs to wait a bit. Good side is that a pause of a week will give plenty of time to discuss about the utility. -- Sami Kerola http://www.iki.fi/kerolasa/ From 8fea1a509c4bafee53202ea598a99b4491283655 Mon Sep 17 00:00:00 2001 From: Sami Kerola kerol...@iki.fi Date: Sat, 2 Jul 2011 17:25:53 +0200 Subject: [PATCH] rename: move command from util-linux to coreutils package * AUTHORS: Add my name. * NEWS: Mention it. * README: Likewise. * doc/coreutils.texi (rename invocation): Add rename info. * man/Makefile.am (rename.1): Add dependency. * man/rename.x: New template. * man/.gitignore: Ignore generated man page. * po/POTFILES.in: Add src/rename.c. * src/.gitignore: Exclude rename. * src/Makefile.am (EXTRA_PROGRAMS): Add rename. * src/rename.c: New file. * tests/Makefile.am (TESTS): Add misc/rename-foo2bar. * tests/misc/rename-foo2bar: New file. Signed-off-by: Sami Kerola kerol...@iki.fi --- AUTHORS |1 + NEWS |4 + README| 10 +- doc/coreutils.texi| 75 ++- man/.gitignore|1 + man/Makefile.am |1 + man/rename.x | 10 + po/POTFILES.in|1 + src/.gitignore|1 + src/Makefile.am |4 + src/rename.c | 563 + tests/Makefile.am |1 + tests/misc/rename-foo2bar | 30 +++ 13 files changed, 696 insertions(+), 6 deletions(-) create mode 100644 man/rename.x create mode 100644 src/rename.c create mode 100755 tests/misc/rename-foo2bar diff --git a/AUTHORS b/AUTHORS index 0c15472..75bc196 100644 --- a/AUTHORS +++ b/AUTHORS @@ -62,6 +62,7 @@ printf: David MacKenzie ptx: François Pinard pwd: Jim Meyering readlink: Dmitry V. Levin +rename: Sami Kerola rm: Paul Rubin, David MacKenzie, Richard M. Stallman, Jim Meyering
rename command
Hello coreutilitarians, I have been lately making some util-linux patches and while doing so I found rename command. It did not take long to realize that the command would be much better if it would support similar switches as mv. To accomplish that reusing gnulib copy functionality felt correct to me, but that is a problem within context of util-linux package, it does not use gnulib and I do not think it will have anytime soon. I proposed to move rename in util-linux mail list from util-linux to coreutils package, and Karel Zak, current util-linux maintainer, responded 'go ahead and ask at coreutils mailing list'. So here we are, would it sound reasonable to take rename command to be part of coreutils? To be a bit more concrete I wrote first version of patch. While the patch is nearly good there are issues. For instance tests/misc/help-version is failing, and I my attempt to fix that was unsuccessful. The command itself poses few implementation questions. Should rename support recursion, and should the rename move files across directories (IMHO that would be unintuitive)? -- Sami Kerola http://www.iki.fi/kerolasa/ From 0822b6d3eb167639747b73d6618bf23a8a99cb35 Mon Sep 17 00:00:00 2001 From: Sami Kerola kerol...@iki.fi Date: Sat, 25 Jun 2011 21:40:10 +0200 Subject: [PATCH] rename: move command from util-linux to coreutils package * AUTHORS: Add my name. * NEWS: Mention it. * README: Likewise. * doc/coreutils.texi (rename invocation): Add rename info. * man/Makefile.am (rename.1): Add dependency. * man/rename.x: New template. * man/.gitignore: Ignore generated man page. * po/POTFILES.in: Add src/rename.c. * src/.gitignore: Exclude rename. * src/Makefile.am (EXTRA_PROGRAMS): Add rename. * src/rename.c: New file. * tests/Makefile.am (TESTS): Add misc/rename-foo2bar. * tests/misc/rename-foo2bar: New file. Signed-off-by: Sami Kerola kerol...@iki.fi --- AUTHORS |1 + NEWS |4 + README| 10 +- doc/coreutils.texi| 75 - man/.gitignore|1 + man/Makefile.am |1 + man/rename.x | 10 ++ po/POTFILES.in|1 + src/.gitignore|1 + src/Makefile.am |4 + src/rename.c | 290 + tests/Makefile.am |1 + tests/misc/rename-foo2bar | 30 + 13 files changed, 423 insertions(+), 6 deletions(-) create mode 100644 man/rename.x create mode 100644 src/rename.c create mode 100755 tests/misc/rename-foo2bar diff --git a/AUTHORS b/AUTHORS index 0c15472..166ab34 100644 --- a/AUTHORS +++ b/AUTHORS @@ -62,6 +62,7 @@ printf: David MacKenzie ptx: François Pinard pwd: Jim Meyering readlink: Dmitry V. Levin +rename: aeb(?), Sami Kerola rm: Paul Rubin, David MacKenzie, Richard M. Stallman, Jim Meyering rmdir: David MacKenzie runcon: Russell Coker diff --git a/NEWS b/NEWS index 619fbdd..a2d0147 100644 --- a/NEWS +++ b/NEWS @@ -19,6 +19,10 @@ GNU coreutils NEWS-*- outline -*- chmod, chown and chgrp now output the original attributes in messages, when -v or -c specified. +** New programs + + rename: Rename multiple files by using pattern. + ** New features split accepts a new --filter=CMD option. With it, split filters output diff --git a/README b/README index eaa5fb0..5d5ff47 100644 --- a/README +++ b/README @@ -11,11 +11,11 @@ The programs that can be built with this package are: csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold groups head hostid hostname id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup - nproc od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir - runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf - sleep sort split stat stdbuf stty su sum sync tac tail tee test timeout - touch tr true truncate tsort tty uname unexpand uniq unlink uptime users - vdir wc who whoami yes + nproc od paste pathchk pinky pr printenv printf ptx pwd readlink rename + rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred + shuf sleep sort split stat stdbuf stty su sum sync tac tail tee test + timeout touch tr true truncate tsort tty uname unexpand uniq unlink + uptime users vdir wc who whoami yes See the file NEWS for a list of major changes in the current release. diff --git a/doc/coreutils.texi b/doc/coreutils.texi index f74dd1c..8fd181b 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -94,6 +94,7 @@ * ptx: (coreutils)ptx invocation. Produce permuted indexes. * pwd: (coreutils)pwd invocation. Print working directory. * readlink: (coreutils)readlink invocation. Print referent of a symlink. +* rename: (coreutils)rename invocation.Rename multiple files. * rm: (coreutils)rm invocation. Remove files
Re: rename command
2011/6/27 Pádraig Brady p...@draigbrady.com: On 27/06/11 10:11, Sami Kerola wrote: Hello coreutilitarians, I have been lately making some util-linux patches and while doing so I found rename command. It did not take long to realize that the command would be much better if it would support similar switches as mv. To accomplish that reusing gnulib copy functionality felt correct to me, but that is a problem within context of util-linux package, it does not use gnulib and I do not think it will have anytime soon. I proposed to move rename in util-linux mail list from util-linux to coreutils package, and Karel Zak, current util-linux maintainer, responded 'go ahead and ask at coreutils mailing list'. So here we are, would it sound reasonable to take rename command to be part of coreutils? Well it's not linux specific. So I suppose it fits more here, than in util-linux. That is true as well. I've never used rename actually, instead using find | sed | sh in the rare times I've had to do something like this. I find that easier and more general, for lower casing etc. That is a process per file though. To be honest if the command would not already exist it should not be taken to any package. Now when it already is in use making it good is the reasonable thing to do. Anyway, I see you're adding these options, to better handle existing files. + fputs (_(\ + --backup[=CONTROL] make a backup of each existing destination file\ +\n\ + -b like --backup but does not accept an argument\n\ + -f, --force do not prompt before overwriting\n\ + -i, --interactive prompt before overwrite\n\ + -n, --no-clobberdo not overwrite an existing file\n\ +If you specify more than one of -i, -f, -n, only the final one takes effect.\n\ + -S, --suffix=SUFFIX override the usual backup suffix\n\ + -v, --verbose explain what is being done\n\ To be a bit more concrete I wrote first version of patch. While the patch is nearly good there are issues. For instance tests/misc/help-version is failing, and I my attempt to fix that was unsuccessful. The command itself poses few implementation questions. Should rename support recursion maybe. and should the rename move files across directories (IMHO that would be unintuitive)? maybe not. --- a/AUTHORS +++ b/AUTHORS @@ -62,6 +62,7 @@ printf: David MacKenzie ptx: François Pinard pwd: Jim Meyering readlink: Dmitry V. Levin +rename: aeb(?), Sami Kerola Andries Brouwer Needs also to be inserted as proper_neme to #define AUTHORS. +* rename invocation::Rename multiple files by using pattern s/by using pattern/using a pattern/ (in NEWS and info) sorry I've not time to review fully, OK. -- Sami Kerola http://www.iki.fi/kerolasa/
[coreutils] [PATCH] uniq: don't continue field processing after end of line
Hi,
I notice uniq -f 'insane_large_number' will make process to be busy
long time without good reason. Attached patch should fix this symptom.
I found the bug after friend of mine asked why uniq does not allow
specifying field separator, similar way sort -t. I could not answer
anything rational, so I look the code and tested how it works. That
inspired me to send bug fix, which is obvious thing to do. But how
about that -t, do you think this would be worth while addition to
uniq?
--
Sami Kerola
http://www.iki.fi/kerolasa/
From 4652493c90940e5460ccfeb8ed3e231e06ee46dc Mon Sep 17 00:00:00 2001
From: Sami Kerola kerol...@iki.fi
Date: Mon, 17 Jan 2011 00:27:06 +0100
Subject: [PATCH] uniq: don't continue field processing after end of line
* NEWS (Bug fixes): Mention it.
* src/uniq.c (find_field): Stop processing loop when end of line
is reached. Before this fix 'uniq -f 100 /etc/passwd' ran
quite long time.
---
NEWS |3 +++
src/uniq.c |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/NEWS b/NEWS
index 9ccad63..71018dd 100644
--- a/NEWS
+++ b/NEWS
@@ -13,6 +13,9 @@ GNU coreutils NEWS-*-
outline -*-
rm -f no longer fails for EINVAL or EILSEQ on file systems that
reject file names invalid for that file system.
+ uniq -f NUM will no longer try to process lines after end of
+ line is reach.
+
* Noteworthy changes in release 8.9 (2011-01-04) [stable]
diff --git a/src/uniq.c b/src/uniq.c
index 7bdbc4f..6fa6cc9 100644
--- a/src/uniq.c
+++ b/src/uniq.c
@@ -214,7 +214,7 @@ find_field (struct linebuffer const *line)
size_t size = line-length - 1;
size_t i = 0;
- for (count = 0; count skip_fields; count++)
+ for (count = 0; count skip_fields count line-length; count++)
{
while (i size isblank (to_uchar (lp[i])))
i++;
--
1.7.3.5
[coreutils] [PATCH] call getenv SIMPLE_BACKUP_SUFFIX only when backups are defined
Hi,
The patch will remove FIXME item from cp, install, ln and mv. I do
acknowledge that getenv (SIMPLE_BACKUP_SUFFIX) does still get to be
called unnecessarily if numbered backups are asked, which is not
perfect, but better than calling it always.
--
Sami Kerola
http://www.iki.fi/kerolasa/
From c73a80e2b8b29564122df4c85a17d4bf5cdabf8b Mon Sep 17 00:00:00 2001
From: Sami Kerola kerol...@iki.fi
Date: Sat, 13 Nov 2010 18:17:05 +0100
Subject: [PATCH] cp/install/ln/mv: call getenv SIMPLE_BACKUP_SUFFIX only when
backups are defined
call getenv SIMPLE_BACKUP_SUFFIX only when backups are defined
* src/cp.c: Likewise.
* src/install.c: Likewise.
* src/ln.c: Likewise.
* src/mv.c: Likewise.
Signed-off-by: Sami Kerola kerol...@iki.fi
---
src/cp.c | 15 +++
src/install.c | 15 +++
src/ln.c | 15 +++
src/mv.c | 15 +++
4 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/src/cp.c b/src/cp.c
index 5b14f3a..1a6552c 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -905,7 +905,7 @@ main (int argc, char **argv)
int c;
bool ok;
bool make_backups = false;
- char *backup_suffix_string;
+ char *backup_suffix_string = NULL;
char *version_control_string = NULL;
struct cp_options x;
bool copy_contents = false;
@@ -923,10 +923,6 @@ main (int argc, char **argv)
selinux_enabled = (0 is_selinux_enabled ());
cp_option_init (x);
- /* FIXME: consider not calling getenv for SIMPLE_BACKUP_SUFFIX unless
- we'll actually use backup_suffix_string. */
- backup_suffix_string = getenv (SIMPLE_BACKUP_SUFFIX);
-
while ((c = getopt_long (argc, argv, abdfHilLnprst:uvxPRS:T,
long_opts, NULL))
!= -1)
@@ -1116,14 +1112,17 @@ main (int argc, char **argv)
usage (EXIT_FAILURE);
}
- if (backup_suffix_string)
-simple_backup_suffix = xstrdup (backup_suffix_string);
-
x.backup_type = (make_backups
? xget_version (_(backup type),
version_control_string)
: no_backups);
+ if (make_backups backup_suffix_string == NULL)
+backup_suffix_string = getenv (SIMPLE_BACKUP_SUFFIX);
+
+ if (backup_suffix_string)
+simple_backup_suffix = xstrdup (backup_suffix_string);
+
if (x.dereference == DEREF_UNDEFINED)
{
if (x.recursive)
diff --git a/src/install.c b/src/install.c
index 467e500..9c48fc9 100644
--- a/src/install.c
+++ b/src/install.c
@@ -427,7 +427,7 @@ main (int argc, char **argv)
int exit_status = EXIT_SUCCESS;
const char *specified_mode = NULL;
bool make_backups = false;
- char *backup_suffix_string;
+ char *backup_suffix_string = NULL;
char *version_control_string = NULL;
bool mkdir_and_install = false;
struct cp_options x;
@@ -456,10 +456,6 @@ main (int argc, char **argv)
dir_arg = false;
umask (0);
- /* FIXME: consider not calling getenv for SIMPLE_BACKUP_SUFFIX unless
- we'll actually use backup_suffix_string. */
- backup_suffix_string = getenv (SIMPLE_BACKUP_SUFFIX);
-
while ((optc = getopt_long (argc, argv, bcCsDdg:m:o:pt:TvS:Z:,
long_options,
NULL)) != -1)
{
@@ -574,14 +570,17 @@ main (int argc, char **argv)
_(cannot force target context to %s and preserve it),
quote (scontext));
- if (backup_suffix_string)
-simple_backup_suffix = xstrdup (backup_suffix_string);
-
x.backup_type = (make_backups
? xget_version (_(backup type),
version_control_string)
: no_backups);
+ if (make_backups backup_suffix_string == NULL)
+ backup_suffix_string = getenv (SIMPLE_BACKUP_SUFFIX);
+
+ if (backup_suffix_string)
+simple_backup_suffix = xstrdup (backup_suffix_string);
+
if (scontext setfscreatecon (scontext) 0)
error (EXIT_FAILURE, errno,
_(failed to set default file creation context to %s),
diff --git a/src/ln.c b/src/ln.c
index 672964c..01c53c0 100644
--- a/src/ln.c
+++ b/src/ln.c
@@ -407,7 +407,7 @@ main (int argc, char **argv)
int c;
bool ok;
bool make_backups = false;
- char *backup_suffix_string;
+ char *backup_suffix_string = NULL;
char *version_control_string = NULL;
char const *target_directory = NULL;
bool no_target_directory = false;
@@ -422,10 +422,6 @@ main (int argc, char **argv)
atexit (close_stdin);
- /* FIXME: consider not calling getenv for SIMPLE_BACKUP_SUFFIX unless
- we'll actually use backup_suffix_string. */
- backup_suffix_string = getenv (SIMPLE_BACKUP_SUFFIX);
-
symbolic_link = remove_existing_files = interactive = verbose
= hard_dir_link = false;
@@ -532,13 +528,16 @@ main (int argc, char **argv)
quote (file[n_files - 1]));
}
- if (backup_suffix_string)
-simple_backup_suffix = xstrdup (backup_suffix_string);
-
backup_type = (make_backups
? xget_version
Re: [coreutils] [PATCH] Cater for extra strace output when building 32-on-64.
On Sat, Oct 30, 2010 at 15:20, Nix n...@esperi.org.uk wrote: +grep -v 'Process PID=[1-9][0-9]* runs in 32 bit mode.' out out-destrace Even thou it's rare PID can be single digit number. Also I don't see grep -v in use for other tests. I think following is better. sed '/Process PID=[0-9]* runs in 32 bit mode./d' out out-destrace -- Sami Kerola http://www.iki.fi/kerolasa/
Re: [PATCH] in place option for unexpand
On Fri, Mar 27, 2009 at 15:20, Sami Kerola kerol...@iki.fi wrote:
Well I changed rename to copy that is part of coreutils and use the
call in move_mode. I did not send new patch because I want to be sure
my employer has signed papers stating that they have no right to my
contributions to coreutils. Perhaps I should wait copyright papers to
get ready before making questions. It's a bit difficult to ask
questions get correct answers when you don't see what I am talking
about.
Hello again,
My legal papers are ready to be sent to Boston. I'll be in touch with
GNU copyright personel tomorrow. Since it should be now safe to send
patches here is next one. Quite honestly I am not 100% happy about it.
The patch does quite much everything that you'd expect, but there are
two issues.
When backup is specified permissions and ownership of mkstemp file are
used. It would make more sense to use destination attributes, but the
copy.c does not support that. I tried write a patch which would do
that, but it was tricker than I expected. And if you think this is
right thing to do I'll invest more of my time to write such patch.
The message The backup suffix is `~', unless... should go to
lib/version-etc.c or somewhere similar. If in-place is implemented to
several command this sort of tactic should be nice to translators.
So what do you think, is the in-place implementation better or worse
when it uses copy.c?
--
Sami Kerola
http://www.iki.fi/kerolasa/
From 04b61ac97f21498f597f131485c58f629b69865d Mon Sep 17 00:00:00 2001
From: Sami Kerola kerol...@iki.fi
Date: Mon, 13 Apr 2009 17:57:04 +0200
Subject: [PATCH] in-place option that uses copy.c
Cc: kerol...@iki.fi
---
src/Makefile.am |3 +
src/unexpand.c | 283 ++
2 files changed, 244 insertions(+), 42 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 9aaf739..d869aaa 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -102,6 +102,7 @@ runcon_LDADD = $(LDADD) $(LIB_SELINUX)
pathchk_LDADD = $(LDADD) $(LIB_EACCESS)
rm_LDADD = $(LDADD) $(LIB_EACCESS)
test_LDADD = $(LDADD) $(LIB_EACCESS)
+unexpand_LDADD = $(LDADD) $(LIB_EACCESS) $(LIB_SELINUX)
# This is for the '[' program. Automake transliterates '[' to '_'.
__LDADD = $(LDADD) $(LIB_EACCESS)
@@ -155,6 +156,7 @@ vdir_LDADD += $(LIB_ACL)
cp_LDADD += $(LIB_ACL) $(LIB_XATTR)
mv_LDADD += $(LIB_ACL) $(LIB_XATTR)
ginstall_LDADD += $(LIB_ACL) $(LIB_XATTR)
+unexpand += $(LIB_ACL) $(LIB_XATTR)
stat_LDADD = $(LDADD) $(LIB_SELINUX)
@@ -265,6 +267,7 @@ mkdir_SOURCES = mkdir.c prog-fprintf.c
rmdir_SOURCES = rmdir.c prog-fprintf.c
uname_SOURCES = uname.c uname-uname.c
+unexpand_SOURCES = unexpand.c $(copy_sources)
arch_SOURCES = uname.c uname-arch.c
md5sum_SOURCES = md5sum.c
diff --git a/src/unexpand.c b/src/unexpand.c
index 93f1ce8..0da7d68 100644
--- a/src/unexpand.c
+++ b/src/unexpand.c
@@ -38,10 +38,16 @@
#include stdio.h
#include getopt.h
#include sys/types.h
+#include selinux/selinux.h
+#include signal.h
+
#include system.h
#include error.h
#include quote.h
#include xstrndup.h
+#include backupfile.h
+#include copy.h
+#include cp-hash.h
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME unexpand
@@ -85,8 +91,23 @@ static bool have_read_stdin;
/* The desired exit status. */
static int exit_status;
-/* Write back file if true */
-static bool in_place;
+/* Use SA_NOCLDSTOP as a proxy for whether the sigaction machinery is
+ present. */
+#ifndef SA_NOCLDSTOP
+# define SA_NOCLDSTOP 0
+/* No sigprocmask. Always 'return' zero. */
+# define sigprocmask(How, Set, Oset) (0)
+# define sigset_t int
+# if ! HAVE_SIGINTERRUPT
+# define siginterrupt(sig, flag) /* empty */
+# endif
+#endif
+
+/* The set of signals that are caught. */
+static sigset_t caught_signals;
+
+/* Write back file(s) if true */
+static bool in_place = false;
/* For long options that have no equivalent short option, use a
non-character as a pseudo short option, starting with CHAR_MAX + 1. */
@@ -101,15 +122,18 @@ struct in_out_files
FILE *infile;
FILE *outfile;
char *temp;
- struct stat st;
};
+struct in_out_files *iofs;
static struct option const longopts[] =
{
{tabs, required_argument, NULL, 't'},
{all, no_argument, NULL, 'a'},
{first-only, no_argument, NULL, CONVERT_FIRST_ONLY_OPTION},
+ {output, required_argument, NULL, 'o'},
{in-place, no_argument, NULL, IN_PLACE_OPTION},
+ {backup, optional_argument, NULL, 'b'},
+ {suffix, required_argument, NULL, 'S'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -142,16 +166,69 @@ Mandatory arguments to long options are mandatory for
short options too.\n\
-t, --tabs=LIST use comma separated LIST of tab positions (enables -a)\n\
), stdout);
fputs (_(\
- --in-place edit files in place\n\
+ --backup[=CONTROL] make a backup of each existing destination file\n
Re: [PATCH] tests: copy.c destination permissions lost when backup specified
On Mon, Mar 30, 2009 at 13:43, Jim Meyering j...@meyering.net wrote: Sami Kerola wrote: Either this is bug or an unintuitive feature. s...@lelux ~/foo touch src dest s...@lelux ~/foo chmod g-rwx src s...@lelux ~/foo chmod g+rwx dest s...@lelux ~/foo ls -l total 0 -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest -rwr-- 1 sake sake 0 2009-03-30 13:16 src s...@lelux ~/foo cp --force --backup=t src dest s...@lelux ~/foo ls -l total 0 -rwr-- 1 sake sake 0 2009-03-30 13:16 dest -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest.~1~ -rwr-- 1 sake sake 0 2009-03-30 13:16 src In case this is bug the patch is good. In case of feature it should be modified to make sure that permissions are different. It's a feature. With --backup, an existing destination is first moved aside (renamed), and thus the backup retains all attributes. That's the idea of making a backup, after all: preserve as much initial state as possible. I give great value for backups, but still I would like to see new and old destination files to have same permissions. Of course when --preserve is specified expectation is changed; source permission should appear for the new file. Am I only one thinking this way? -- Sami Kerola http://www.iki.fi/kerolasa/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] tests: copy.c destination permissions lost when backup specified
Hi, Either this is bug or an unintuitive feature. s...@lelux ~/foo touch src dest s...@lelux ~/foo chmod g-rwx src s...@lelux ~/foo chmod g+rwx dest s...@lelux ~/foo ls -l total 0 -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest -rwr-- 1 sake sake 0 2009-03-30 13:16 src s...@lelux ~/foo cp --force --backup=t src dest s...@lelux ~/foo ls -l total 0 -rwr-- 1 sake sake 0 2009-03-30 13:16 dest -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest.~1~ -rwr-- 1 sake sake 0 2009-03-30 13:16 src In case this is bug the patch is good. In case of feature it should be modified to make sure that permissions are different. -- Sami Kerola http://www.iki.fi/kerolasa/ From 2c4e6f75ced048ec24c13ec8862bc6ae0a6ddb4d Mon Sep 17 00:00:00 2001 From: Sami Kerola kerol...@iki.fi Date: Mon, 30 Mar 2009 13:11:26 +0200 Subject: [PATCH] check that dest and backup permissions are same Cc: kerol...@iki.fi --- tests/cp/backup-dst-perm | 51 ++ 1 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 tests/cp/backup-dst-perm diff --git a/tests/cp/backup-dst-perm b/tests/cp/backup-dst-perm new file mode 100644 index 000..4d6b12c --- /dev/null +++ b/tests/cp/backup-dst-perm @@ -0,0 +1,51 @@ +#!/bin/sh +# +# Test cp destination permissions are not changed when --backup specified +# and source permissions are not asked to be preserved (-p). +# +# Copyright (C) 1997, 1999, 2002, 2004, 2006-2008 Free Software Foundation, Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +if test $VERBOSE = yes; then + set -x + cp --version +fi + +. $srcdir/test-lib.sh + +file_src=bdpa +file_dst=bdpb +temp_files=$file_src $file_dst +rm -f $temp_files + +fail=0 +touch $temp_files || fail=1 +chmod g-rwx $file_src +chmod g+rwx $file_dst + +# Specify both version control and suffix so the environment variables +# (possibly set by the user running these tests) aren't used. +cp --force --backup=t $file_src $file_dst || fail=1 + +test -f $file_src || fail=1 +test -f $file_dst || fail=1 +test -f $file_dst.~1~ || fail=1 + +dst_mode=`ls -ld $file_dst|cut -b-10` +backup_mode=`ls -ld $file_dst.~1~|cut -b-10` + +test $backup_mode = $dst_mode || fail=1 + +Exit $fail -- 1.6.0.6 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] in place option for unexpand
2009/3/27 Pádraig Brady p...@draigbrady.com:
Sami Kerola wrote:
Mean while I've continued with a first patch. I am having a hard time
with cp_option_init. My source file is created by mkstemp which causes
permissions to be 600. What ever I do with preserve permissions bits I
always seem to get source file permissions in place. Am I such an
amateur that I am not seeing something obvious, or is it really so
that there is no preserve destination permissions?
I'm a little confused by what you mean by mkstemp here.
As a first step to support an `in-place cmd files` shell script,
you would need a cp --attributes-only option which should
do what cp does now but not do any read() or write() any data.
That would be generally useful option anyway outside of
an in place editing stuff.
Well I changed rename to copy that is part of coreutils and use the
call in move_mode. I did not send new patch because I want to be sure
my employer has signed papers stating that they have no right to my
contributions to coreutils. Perhaps I should wait copyright papers to
get ready before making questions. It's a bit difficult to ask
questions get correct answers when you don't see what I am talking
about.
1. grep 127.0.0.1 /etc/hosts |
writeafter /etc/hosts
That interface seems useful, but note the `sponge` command
from moreutils which I just remembered after your example.
Note sponge can rename() and loose some attributes from
a quick glance at the code.
ACK. After writing good --in-place patch(es) for coreutils I might
contribute to moreutils.
2. echo /etc/passwd /etc/shadow |
writeafter -I '{}' grep root '{}'
Does that sound like something reasonable? If yes, it might take a
while to come up with a well working implementation but I'm sure
that's doable.
that seems a little over complicated as I can't see one
needing to split files to edit and files to process on
position like that.
You might be right. If there is ones in life time usage for that one
should use sponge in for loop.
--
Sami Kerola
http://www.iki.fi/kerolasa/
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] in place option for unexpand
On Sun, Mar 22, 2009 at 10:58, Jim Meyering j...@meyering.net wrote:
Sami Kerola wrote:
On Sun, Mar 22, 2009 at 08:22, Jim Meyering j...@meyering.net wrote:
Pádraig Brady wrote:
Sami Kerola wrote:
Good weekend,
If you consider in-line option is useful for unexpand I could wrote
another patch for expand command which will do the same thing.
Thanks for this. I'm wondering about usefulness to other coreutils.
Perhaps fmt,fold,nl,tac,tr would also benefit in addition to expand
unexpand?
I think it sounds good idea that there are functions in coreutils lib
which implement the in-place. Unfortunately I am not good enough
programmer to come up with a routine that fits for all of the coreutil
programs. IMHO Making one command work right, converting the
functionality to general routine and monify rest of the commands is
right aproach.
We prefer not to modify many programs, when adding
a single new helper program can produce the same result.
The Unix Philosophy...
...
BTW, I like the way you use $TMPDIR etc. contrary to the `sed` --in-place
option which uses a tmp file in the same dir as the original.
Using the same dir will fail in the case you've a file in a readonly dir
bind mounted to a writeable location for example.
On the otherhand it requires more code to support. For example
I think your rename() will fail if $TMPDIR is on
a different filesystem to the original file?
Yes. That is a disadvantage of using $TMPDIR.
And that will be fixed ones copy is approach in use. Then I just need
remember to unlink leftover file.
It's better (atomic) to use rename, and hence a temporary
file on the same partition as the file in question.
IMHO, requiring that the containing directory be writable is
not a problem.
Updates.
License conditions are under work. Initial contact with GNU boston
office is done and my boss is figuring out how to get this sort of
paper work done.
Mean while I've continued with a first patch. I am having a hard time
with cp_option_init. My source file is created by mkstemp which causes
permissions to be 600. What ever I do with preserve permissions bits I
always seem to get source file permissions in place. Am I such an
amateur that I am not seeing something obvious, or is it really so
that there is no preserve destination permissions?
I also gave a thought to that general wrapper. By waving hands it
should be a tool that can handle 1. writes after pipe and 2. xargs
style in-placement. My work name for the command is writeafter. The
two usage cases in my theory should look something like this.
1. grep 127.0.0.1 /etc/hosts |
writeafter /etc/hosts
2. echo /etc/passwd /etc/shadow |
writeafter -I '{}' grep root '{}'
Does that sound like something reasonable? If yes, it might take a
while to come up with a well working implementation but I'm sure
that's doable.
--
Sami Kerola
http://www.iki.fi/kerolasa/
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] in place option for unexpand
Good weekend,
If you consider in-line option is useful for unexpand I could wrote
another patch for expand command which will do the same thing.
--
Sami Kerola
http://www.iki.fi/kerolasa/
From ef6192da066dcf3c65bc9a672ecf78c30894ac95 Mon Sep 17 00:00:00 2001
From: Sami Kerola kerol...@iki.fi
Date: Sat, 21 Mar 2009 18:23:04 +0100
Subject: [PATCH] in place option for unexpand
Cc: kerol...@iki.fi
---
src/unexpand.c | 116 +--
1 files changed, 95 insertions(+), 21 deletions(-)
diff --git a/src/unexpand.c b/src/unexpand.c
index 9f6a6d7..93f1ce8 100644
--- a/src/unexpand.c
+++ b/src/unexpand.c
@@ -85,11 +85,23 @@ static bool have_read_stdin;
/* The desired exit status. */
static int exit_status;
+/* Write back file if true */
+static bool in_place;
+
/* For long options that have no equivalent short option, use a
non-character as a pseudo short option, starting with CHAR_MAX + 1. */
enum
{
- CONVERT_FIRST_ONLY_OPTION = CHAR_MAX + 1
+ CONVERT_FIRST_ONLY_OPTION = CHAR_MAX + 1,
+ IN_PLACE_OPTION
+};
+
+struct in_out_files
+{
+ FILE *infile;
+ FILE *outfile;
+ char *temp;
+ struct stat st;
};
static struct option const longopts[] =
@@ -97,6 +109,7 @@ static struct option const longopts[] =
{tabs, required_argument, NULL, 't'},
{all, no_argument, NULL, 'a'},
{first-only, no_argument, NULL, CONVERT_FIRST_ONLY_OPTION},
+ {in-place, no_argument, NULL, IN_PLACE_OPTION},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -128,6 +141,9 @@ Mandatory arguments to long options are mandatory for short
options too.\n\
-t, --tabs=N have tabs N characters apart instead of 8 (enables -a)\n\
-t, --tabs=LIST use comma separated LIST of tab positions (enables -a)\n\
), stdout);
+ fputs (_(\
+ --in-place edit files in place\n\
+), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
emit_bug_reporting_address ();
@@ -234,41 +250,90 @@ validate_tab_stops (uintmax_t const *tabs, size_t entries)
Open a filename of `-' as the standard input.
Return NULL if there are no more input files. */
-static FILE *
-next_file (FILE *fp)
+static struct in_out_files *
+next_file (struct in_out_files *iofs)
{
static char *prev_file;
char *file;
+ char pattern[] = unexpandXX;
+ char *tmpdir = NULL;
- if (fp)
+ if (iofs-infile)
{
- if (ferror (fp))
+ if (ferror (iofs-infile))
{
error (0, errno, %s, prev_file);
exit_status = EXIT_FAILURE;
}
if (STREQ (prev_file, -))
- clearerr (fp); /* Also clear EOF. */
- else if (fclose (fp) != 0)
+ clearerr (iofs-infile);/* Also clear EOF. */
+ else
{
- error (0, errno, %s, prev_file);
- exit_status = EXIT_FAILURE;
- }
+ if (fclose (iofs-infile) != 0)
+ {
+ error (0, errno, %s, prev_file);
+ exit_status = EXIT_FAILURE;
+}
+ if (in_place (fclose (iofs-outfile) != 0))
+{
+ error (0, errno, %s, iofs-temp);
+ exit_status = EXIT_FAILURE;
+}
+ if (rename(iofs-temp, prev_file))
+{
+ error (0, errno, moving a temporary file in place failed);
+ exit_status = EXIT_FAILURE;
+}
+ if (chmod(prev_file, iofs-st.st_mode))
+{
+ error (0, errno, resetting file mode failed);
+ exit_status = EXIT_FAILURE;
+}
+}
}
while ((file = *file_list++) != NULL)
{
if (STREQ (file, -))
{
+ if (in_place)
+ error (EXIT_FAILURE, 0, _(in place and reading stdin cannot be
combined));
have_read_stdin = true;
prev_file = file;
- return stdin;
+ iofs-infile = stdin;
+ iofs-outfile = stdout;
+ return iofs;
}
- fp = fopen (file, r);
- if (fp)
+ iofs-infile = fopen (file, r);
+ fstat(fileno (iofs-infile), (iofs-st));
+ if (iofs-infile)
{
prev_file = file;
- return fp;
+ if (in_place)
+ {
+ if (! ((tmpdir=getenv(TMPDIR
+{
+ tmpdir=getenv(TMP);
+}
+ if (!tmpdir)
+{
+ tmpdir = /tmp;
+}
+ iofs-temp = xmalloc(strlen(tmpdir) + strlen(pattern) + 2);
+ strcpy(iofs-temp, tmpdir);
+ strcat(iofs-temp, /);
+ strcat(iofs-temp, pattern);
+ if (mkstemp(iofs-temp) == 0 ||
+ (iofs-outfile = fopen(iofs-temp, w)) == NULL)
+ {
+ error (EXIT_FAILURE, 0, _(creating a tmpfile failed));
+ }
+ }
+ else
