bug#17904: issue with split command
Hi Andreas,
PFB means please find below :-) (sorry for the confusing acronym)
Well, as far as splitting it to separate folder is concerned, I am sure the
newly created files can never be more than 1000KB. Usually the split up files
are around 250KB - 300KB in size.
Thank You,
V. Jayaprakash
-Original Message-
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Sent: 03 July 2014 18:41
To: Vambara, Jayaprakash
Cc: 17...@debbugs.gnu.org
Subject: Re: bug#17904: issue with split command
jayaprakash.vamb...@essent.nl writes:
I am using split command to split a large file and later I am renaming file.
PFB command.
What does PFB mean?
find . -size +1000 -exec split -l 1 {\} {}-new \;
This may find the newly created files, splitting them again if any of the
produced files is bigger then 1000 bytes. You should produce the output in a
separate directory not located below the current one.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And
now for something completely different.
bug#17904: issue with split command
jayaprakash.vamb...@essent.nl writes: Well, as far as splitting it to separate folder is concerned, I am sure the newly created files can never be more than 1000KB. Usually the split up files are around 250KB - 300KB in size. The default unit for -size is actually 512 bytes, thus the limit is 500KB. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bug#17936: [SUGGESTION] cp behavior
GNU Developers: I would like to make a suggestion for the cp command. As we all know, the cp command accepts two arguments (cp SRC DEST). Could someone add a little feature to give the cp command an interesting feature that the copy command on DOS uses? On DOS, when copy is given one argument (the source file), the command will assume the destination is the current working directory. Can such a feature be added to cp? It is awful that a command by Microsuck has an awesome feature that no Unix, Linux, or GNU guru has added to the popular GNU-coreutils command. Also, if such a feature is added to cp, can mv also get the same feature? Thanks, Devyn Collier Johnson devyncjohn...@gmail.com
bug#17937: Getting gnu touch and gnu date to play nicely
Most of the time I love Linux CLI, but rare occasions like this s*** makes me want to throw my computer through the wall! From the touch manpage. -d, --date=STRING parse STRING and use it instead of current time ~$ touch -d=now file touch: invalid date format ‘=now’ ~$ touch -d=$(date) file touch: invalid date format ‘=Fri Jul 4 06:05:22 EDT 2014’ ~$ touch -d=$(date -R) file touch: invalid date format ‘=Fri, 04 Jul 2014 06:05:30 -0400’ ~$ touch -d=$(date -u) file touch: invalid date format ‘=Fri Jul 4 10:05:33 UTC 2014’ Is it possible that touch could get an update to support the common output provided by the gnu version of `date`?
bug#17937: Getting gnu touch and gnu date to play nicely
tag 17937 notabug close 17937 stop On 07/04/2014 11:18 AM, sepero...@gmx.com wrote: Most of the time I love Linux CLI, but rare occasions like this s*** makes me want to throw my computer through the wall! From the touch manpage. -d, --date=STRING parse STRING and use it instead of current time ~$ touch -d=now file touch: invalid date format ‘=now’ ~$ touch -d=$(date) file touch: invalid date format ‘=Fri Jul 4 06:05:22 EDT 2014’ ~$ touch -d=$(date -R) file touch: invalid date format ‘=Fri, 04 Jul 2014 06:05:30 -0400’ ~$ touch -d=$(date -u) file touch: invalid date format ‘=Fri Jul 4 10:05:33 UTC 2014’ Is it possible that touch could get an update to support the common output provided by the gnu version of `date`? They'll mostly work if you remove the '='
bug#17936: [SUGGESTION] cp behavior
tag 17936 wontfix close 17936 stop On 07/04/2014 01:55 PM, Devyn Collier Johnson wrote: GNU Developers: I would like to make a suggestion for the cp command. As we all know, the cp command accepts two arguments (cp SRC DEST). Could someone add a little feature to give the cp command an interesting feature that the copy command on DOS uses? On DOS, when copy is given one argument (the source file), the command will assume the destination is the current working directory. Can such a feature be added to cp? It is awful that a command by Microsuck has an awesome feature that no Unix, Linux, or GNU guru has added to the popular GNU-coreutils command. Also, if such a feature is added to cp, can mv also get the same feature? Not at this stage no. You can easily add a function it your shell config to provide this as a wrapper. Consider the issue with: cd dangerous safe=blah cp trigger $Safe #oops typo = silent erroneous behavior thanks, Pádraig.
bug#17937: Getting gnu touch and gnu date to play nicely
sepero...@gmx.com wrote: -d, --date=STRING parse STRING and use it instead of current time The syntax of the command line is documented mostly the same for all of the tools. The challenge is to document these in the online --help documentation (also used for the man page) succinctly and yet still accurately convey the needed information. The above is the standard way all of the GNU coreutils uses to document options. This style of syntax documentation is further described in the Common options section of the manual. If you have GNU Coreutils installed then this will be available on your system directly with: info coreutils 'Common options' An online web copy of the most current version is here: https://www.gnu.org/software/coreutils/manual/coreutils.html#Common-options ~$ touch -d=now file touch: invalid date format ‘=now’ Literally the -d option takes one argument. In the above you are passing the =now option to the touch -d option. This is reflected in the error message. Notice that it says =now including the '=' character? The single letter option is the traditional way to specify Unix options. GNU extends with this long names for options. Long options are nice because they are self-documenting for scripts. And by avoiding the single letter namespace they can be created without consuming the very few single letters available. In order to specify long options we use two dashes -- to signify that a long option is coming next. Literally that is one '-' to start option processing on the string and another '-' to indicate that it is a long option. But then with long options there is a problem. When does the long option stop? We use an equal '=' character to signify the end of the long string option name. The '-' and '=' are bookends for the option name. The value occurs after the '='. But that is only when using the long option syntax. These are equivalent $ touch -d now foo $ touch --date=now foo ~$ touch -d=$(date) file touch: invalid date format ‘=Fri Jul 4 06:05:22 EDT 2014’ ~$ touch -d=$(date -R) file touch: invalid date format ‘=Fri, 04 Jul 2014 06:05:30 -0400’ ~$ touch -d=$(date -u) file touch: invalid date format ‘=Fri Jul 4 10:05:33 UTC 2014’ Notice the '=' in each of the error messages. If you had tried the same using date you would see the same problem. $ date -d=now date: invalid date ‘=now’ However if you use the expected syntax then date works okay. $ date -d now $ date --date=now Is it possible that touch could get an update to support the common output provided by the gnu version of `date`? Of course by now you already know that it does and the problem was simply one of usage with an extra '=' character. :-) But let me take this opportunity to point out that 'touch' is one the commands standardized by POSIX and this includes standardizing the -d option. But note that while GNU extends the capabilities of many utilities and here date parsing quite a large amount the other operating systems do not include those extensions. Other operating systems do what they have always done before. POSIX is standardizing on the portable behavior between operating systems. This means that if you use the portable syntax that it will be ensured to operate the same everywhere. Therefore I recommend using the portable syntax for the least amount of problems. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html The syntax specified there is -MM-DDThh:mm:SS[.frac][tz] or the form with a ',' for the radix mark and many examples are included in that reference. Therefore I recommend using the same syntax. $ date +%FT%T.%N%z 2014-07-04T14:00:10.142621255-0600 And nicely the above is also the same as --iso=8601=ns option. $ date --iso-8601=ns 2014-07-04T14:00:19,278445062-0600 If that syntax is used then touch is happy. I mention that since you were using date's output as input to touch that it is that format which would be best. $ touch -d $(date +%FT%T.%N%z) foo $ touch -d $(date --iso-8601=ns) foo Obviously there isn't much reason to use date like above with touch since that is the default behavior for touch without it. I am sure the reason to use date was to do date calculations. I was just keeping it simple for the above example. But I realize that in a real example it should include some type of date calculation. $ touch -d $(date -d last thursday 12:00 +%FT%T.%N%z) foo As in the FAQ entry on date it is good to always perform date calculations either at a specific time such as noon to avoid Daylight Savings Time issues or use UTC to avoid DST issues. Here is the date FAQ entry. https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e Hope this discussion helps, Bob
bug#17937: Getting gnu touch and gnu date to play nicely
As a additional notice, I apologize for not referring to CLI as GNU tools. My point is simply that it would be very convenient to be able to set the GNU touch -t argument using standard GNU date output. On 07/04/2014 06:18 AM, sepero...@gmx.com wrote: Most of the time I love Linux CLI, but rare occasions like this s*** makes me want to throw my computer through the wall! From the touch manpage. -d, --date=STRING parse STRING and use it instead of current time ~$ touch -d=now file touch: invalid date format ‘=now’ ~$ touch -d=$(date) file touch: invalid date format ‘=Fri Jul 4 06:05:22 EDT 2014’ ~$ touch -d=$(date -R) file touch: invalid date format ‘=Fri, 04 Jul 2014 06:05:30 -0400’ ~$ touch -d=$(date -u) file touch: invalid date format ‘=Fri Jul 4 10:05:33 UTC 2014’ Is it possible that touch could get an update to support the common output provided by the gnu version of `date`?
