bug#8782: date command
James Youngman wrote: On Thu, Jun 2, 2011 at 10:11 AM, Jim Meyering j...@meyering.net wrote: Pádraig Brady wrote: OK how about I put the last 3 or 4 examples from http://www.pixelbeat.org/cmdline.html#dates in an EXAMPLE section in the man page. Good examples. I like the idea. One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. Good idea. That makes it immune to failure in a one hour interval on the day before the spring DST transition.
bug#8782: date command
Jim Meyering wrote: James Youngman wrote: One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. Good idea. That makes it immune to failure in a one hour interval on the day before the spring DST transition. hmm, shouldn't the tomorrow handling be fixed then? -- Berny
bug#8782: date command
Voelker, Bernhard wrote: Jim Meyering wrote: James Youngman wrote: One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. Good idea. That makes it immune to failure in a one hour interval on the day before the spring DST transition. hmm, shouldn't the tomorrow handling be fixed then? Hi Voelker, Fixed how? To retry in that very unusual case? Let's ignore that someone might depend on the current failure, e.g., to locate a DST transition. Note that tomorrow is equivalent to +1 day, aka +24 hours. Upon retry would you use +23 hours or +25 hours? Something else? I don't think it's feasible to change it. This is well documented in the FAQ, and probably in the manual, too.
bug#8782: date command
Jim Meyering wrote: Voelker, Bernhard wrote: Jim Meyering wrote: James Youngman wrote: One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. Good idea. That makes it immune to failure in a one hour interval on the day before the spring DST transition. hmm, shouldn't the tomorrow handling be fixed then? Hi Voelker, Fixed how? To retry in that very unusual case? Let's ignore that someone might depend on the current failure, e.g., to locate a DST transition. that's BAD (tm) usage, IMHO Note that tomorrow is equivalent to +1 day, aka +24 hours. Upon retry would you use +23 hours or +25 hours? Something else? I don't think it's feasible to change it. I admit it's hard. From the user's point of view, there's always a date 24 hours from now on. And the user wants to know what date this would be ... This is well documented in the FAQ, and probably in the manual, too. yes, it is. But as I'm following this ML for ~2 years now, this topic has popped up several times. It seems there's room for improvement. -- Bye, Berny
bug#8782: date command
On 06/03/11 01:52, Voelker, Bernhard wrote: It seems there's room for improvement. Absolutely. All that we need is someone to volunteer to specify exactly how to improve it, and to write the documentation and code. Unfortunately, this won't be trivial.
bug#8782: date command
Voelker, Bernhard wrote: Jim Meyering wrote: Voelker, Bernhard wrote: Jim Meyering wrote: James Youngman wrote: One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. Good idea. That makes it immune to failure in a one hour interval on the day before the spring DST transition. hmm, shouldn't the tomorrow handling be fixed then? Hi Voelker, Fixed how? To retry in that very unusual case? Let's ignore that someone might depend on the current failure, e.g., to locate a DST transition. that's BAD (tm) usage, IMHO Note that tomorrow is equivalent to +1 day, aka +24 hours. Upon retry would you use +23 hours or +25 hours? Something else? I don't think it's feasible to change it. I admit it's hard. From the user's point of view, there's always a date 24 hours from now on. And the user wants to know what date this would be ... We can't change the fact that the spring DST transition introduces a one-hour hole containing invalid times. Whenever we tell date to use a time in such a hole, date must diagnose it as invalid. This is well documented in the FAQ, and probably in the manual, too. yes, it is. But as I'm following this ML for ~2 years now, this topic has popped up several times. It seems there's room for improvement. Making a technical change will be a challenge, to say the least. People are learning that this hole can make date fail. As I see it, education is the way to go.
bug#8782: date command
Jim Meyering wrote: Voelker, Bernhard wrote: Jim Meyering wrote: Voelker, Bernhard wrote: Jim Meyering wrote: James Youngman wrote: One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in the example. Good idea. That makes it immune to failure in a one hour interval on the day before the spring DST transition. hmm, shouldn't the tomorrow handling be fixed then? Hi Voelker, Fixed how? To retry in that very unusual case? Let's ignore that someone might depend on the current failure, e.g., to locate a DST transition. that's BAD (tm) usage, IMHO Note that tomorrow is equivalent to +1 day, aka +24 hours. Upon retry would you use +23 hours or +25 hours? Something else? I don't think it's feasible to change it. I admit it's hard. From the user's point of view, there's always a date 24 hours from now on. And the user wants to know what date this would be ... We can't change the fact that the spring DST transition introduces a one-hour hole containing invalid times. Whenever we tell date to use a time in such a hole, date must diagnose it as invalid. `date` is still a tool, so I feel it should reflect daily life ... I I don't feel I have a 1h gap in spring, do you? ;-)
bug#8782: date command
Voelker, Bernhard wrote: ... We can't change the fact that the spring DST transition introduces a one-hour hole containing invalid times. Whenever we tell date to use a time in such a hole, date must diagnose it as invalid. `date` is still a tool, so I feel it should reflect daily life ... I I don't feel I have a 1h gap in spring, do you? ;-) I do notice it when I have one hour more or less to sleep. I'd say that this tool does reflect daily life. With date you have to be careful about the DST transitions, just as you have to adjust clocks twice a year.
bug#8782: date command
Jim Meyering wrote: Voelker, Bernhard wrote: ... We can't change the fact that the spring DST transition introduces a one-hour hole containing invalid times. Whenever we tell date to use a time in such a hole, date must diagnose it as invalid. `date` is still a tool, so I feel it should reflect daily life ... I I don't feel I have a 1h gap in spring, do you? ;-) I do notice it when I have one hour more or less to sleep. admitted. I'd say that this tool does reflect daily life. With date you have to be careful about the DST transitions, just as you have to adjust clocks twice a year. so in the night where the DST transition takes place, imagine you get up to go to the toilet because you drank to much coffee the evening before ... right in the hour where DST transition happens: isn't there a `date`? Or the other way round: how many hours do you have to left to sleep until 8am? The situation with date sounds like there is an hour once per year when no date exists, but this is not true.
bug#8782: date command
On Friday 03 June 2011, Voelker, Bernhard wrote: so in the night where the DST transition takes place, imagine you get up to go to the toilet because you drank to much coffee the evening before ... right in the hour where DST transition happens: isn't there a `date`? Or the other way round: how many hours do you have to left to sleep until 8am? The situation with date sounds like there is an hour once per year when no date exists, but this is not true. There was no 2011-05-27 02:01:00 in Germany. I am 100% sure nobody in Germany was on toilet on at this time. At this date if you go at 01:59:00 and come back at 03:02:00 then you where 3 minutes on toilet but you was not at 2:01:00 because this time simply does not exist at this day. This works as expected: $ export TZ=Europe/Berlin $ date -d 2011-03-27 02:01:00 date: invalid date `2011-03-27 02:01:00' $ date -d 2011-03-26 02:01:00 tomorrow Sun Mar 27 03:01:00 CEST 2011 cu, Rudi
bug#8796: I need help piping csplit
Hi I have an issue, I'm trying to split several files into two the first one is the head of file and the next one has to start with some title, but csplit don't allowe me to piping, this is how i'm doing $ find ./ -name '*out' | xargs csplit '/All Frequencies/' '/Statistical/' I have to now all the locations of files that ends with out, next every time the command finds a file I want to csplited but terminal sends me an error: csplit: cannot be open «/Statistical/» to read: file or extension don't exist-- * *_¬\_ ___ ( ¬¸|| Julio César González Torres|| | \ »── || UAM-Azcapotzalco FAMA || | V() ─ L // |_ |_* *
bug#8796: I need help piping csplit
tag 8796 notabug
close 8796
thanks
On 06/03/2011 01:46 PM, Julio Cesar Gonzalez Torres wrote:
Hi I have an issue, I'm trying to split several files into two the first one
is the head of file and the next one has to start with some title, but
csplit don't allowe me to piping, this is how i'm doing
$ find ./ -name '*out' | xargs csplit '/All Frequencies/' '/Statistical/'
I have to now all the locations of files that ends with out, next every
time the command finds a file I want to csplited but terminal sends me an
error:
csplit: cannot be open «/Statistical/» to read: file or extension don't
exist--
Thanks for the report. However, this is not a bug in coreutils, but in
your usage of xargs. So I'm marking it closed.
It helps to insert 'echo' prior to 'csplit' to see what you are calling:
csplit '/All Frequencies/' '/Statistical/' file1out file2out ...out
But csplit is documented as requiring a single file name, followed by
multiple patterns.
What you WANT to do is:
find . -name '*out' | \
xargs -I{} csplit {} '/All Frequencies/' '/Statistical'/
The use of -I{} forces xargs to use one file per csplit invocation
(instead of cramming in as many files as possible), as well as to let
you choose where to substitute the file name 9rather than cramming it on
as the last argument).
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
bug#8796: I need help piping csplit
On 06/03/2011 03:44 PM, Eric Blake wrote:
But csplit is documented as requiring a single file name, followed by
multiple patterns.
What you WANT to do is:
find . -name '*out' | \
xargs -I{} csplit {} '/All Frequencies/' '/Statistical'/
Or, ditch xargs altogether, and do it all through find:
find . -name '*out' -exec csplit {} /All Frequencies/ /Statistical/ \;
which has the added benefit of avoiding problems with any *out files
that have embedded newlines.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
