bug#7997: Feature request for date command
For date input (using --date=STRING) you can use the TZ variable to specify the input timezone. Here is an example. $ date -R --date='TZ=Europe/Rome 2004-10-31 06:30' Sat, 30 Oct 2004 23:30:00 -0600 $ TZ=America/New_York date -R --date='TZ=Europe/Paris 2004-10-31 06:30' Sun, 31 Oct 2004 01:30:00 -0400 That does the job, but it is not documented in the manual. Could you document it, and add these examples? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org
bug#7997: Feature request for date command
It should be possible to specify a timezone such as Europe/Rome for the date input. That works in TZ to control the output, so it should work in the input too. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org
Re: Bug in pr?
Sorry, I see I wasn't clear. By omitting the trailer I meant that GNU pr attempted to print on the very last line of the output page, omitting the usual trailer of 5 blank lines at the bottom of the output page. Ok, I guess we should try that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in pr?
Omitting the trailer causes GNU pr to try to print on the very last line of the output page, which is a portability hassle: some printers and printer emulators ignore newline before formfeed on the last line of a page, while others don't. Wouldn't the trailer force a move to the next page, exactly the opposite of what we want? submit a patch along those lines shortly, to bug-coreutils. This is an incompatible change, since it will output 7 fewer lines per page when you specify -F; Don't you mean 7 more lines? I don't follow. Anyway, if this change means less output per page, why do it? I'd rather change just enough to fix the problem. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in pr?
Perhaps you can simply filter the output of pr through a filter to eliminate the offending newline(s)? Maybe I could, but that seems to be an answer to the wrong question. The question is not how I can get good printouts. The question is how to make our various programs work right together, for everyone. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dired-move-to-filename-regexp
Ideally ls would accept a new --format=FMT option that would work like find's printf format string. Then it'd be easy to add a new option to make ls use a format string with fixed widths to restore the old behavior. Would you like to implement that? If that's the solution you prefer, it will certainly work. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dired-move-to-filename-regexp
That would be rather unreliable, since it would need to figure out the number of spaces between fields in both the new output and the old buffer. The gains that we got from --dired would be lost. I won't accept this approach. Of course, the filename part would be determined just as it is now (using the --dired data if available, for example). Ok, you're right about that part. When using --dired, we would still reliably find the filename. But finding where to insert extra spaces would not be entirely reliable, just as finding the file name was not entirely reliable in the past. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dired-move-to-filename-regexp
Another solution is to assume that the current buffer and the one new line have used the same ls options and contain the same number of space-separated fields. Based on this, you can add spaces so as to align the fields in the new line to the field of the other lines. That would be rather unreliable, since it would need to figure out the number of spaces between fields in both the new output and the old buffer. The gains that we got from --dired would be lost. I won't accept this approach. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dired-move-to-filename-regexp
I think a better solution is if we can turn off the new feature of adapting the column widths to the data. One way would be to extend --format to allow fairly arbitrary formats that can specify column widths. For example, Emacs could do this: ls --format='%11m %2l %8o %8g %7s %12d %f' Sure, this would do the job, but I think it would be extra work and add no real benefit. However, if Meyering wants to do it, I won't object to it. Another possibility is to have a new option to disable the new feature, e.g. ls --traditional-column-widths. This would be a bit easier to implement, but would be less general We don't need extra generality just for generality's sake. and might have problems of its own (e.g., users and implementations don't agree on what the traditional widths are). This problem is not real. For Dired to work right when GNU ls is installed, we need only that GNU ls be consistent with itself when --traditional-column-widths is used. I understand that some non-GNU ls implementations also adapt column widths to data, so the Emacs problem would remain with these implementations, regardless of how we change GNU ls. We can suggest installing GNU ls. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dired-move-to-filename-regexp
It maybe a bit less work, but it's certainly not better -- without the auto-adjustment feature, it simply would use absurdly large amounts of whitespace _just in case_ a file happens to be hundreds of gigabytes in size and have thousands of links. If ls does what ls used to do, it won't be worse than it was. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dired-move-to-filename-regexp
I think a better solution is if we can turn off the new feature of adapting the column widths to the data. It is simple and clean. Both this and your suggestion would only work with GNU ls, so in that regard neither one has an advantage. Meyering, what do you think? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
