bug#45695: Date does not work for dates before 1970
On Wed, 6 Jan 2021, at 16:34, zed991 wrote: > On linux, I can use date +%s --date "31 Dec 1969" > The result is -9 > A negative number > > But when I try it on Windows (using GNUWin32) it gives me an error - > "invalid date" > > I downloaded date for windows from this link - > http://gnuwin32.sourceforge.net/packages/coreutils.htm That specific page refers to coreutils 5.3.0, which was published in 2005. The gnuwin32 website in general doesn't appear to have been updated in over 10 years. My personal recommendation to run coreutils on Windows is WSL2, but there are other options (cygwin etc.) Cheers, Phil
bug#45700: rm should not prompt if ! isatty(2)
Thanks for your reply, Paul! I see what you're talking about; thanks for the link. The POSIX spec seems broken in that regard. I guess I'm going to be adding -f to my scripts! (I was surprised to see my script hang today for this very reason). Maybe something could be added to the FAQ or the manpage? I didn't see anything documented about prompting for an unwritable file. Although I'd seen those prompts before, I was surprised to find that prompting happens even when stdout is not a tty. Something like this maybe: Per the POSIX spec, rm will prompt to stderr before removing an unwritable file, even if stderr is not a tty. Another possibility is to add a timeout on the prompt when writing a prompt to a non-tty (with an inferred reply of "no"). -- John On Wednesday, January 6, 2021, 2:17:00 PM EST, Paul Eggert wrote: On 1/6/21 10:56 AM, John Wiersba via GNU coreutils Bug Reports wrote: > $ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove > write-protected regular empty file 'asdf'? # should*not* prompt > > If the prompt cannot be seen, then it can't be properly answered, so there is > no point in prompting and consequently leaving the user with a hanging > command and no way to know what's being expected of them. Instead rm should > attempt to remove the file and succeed or fail based on the result. POSIX requires the current behavior; see clause 3 in: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html Although GNU rm needn't follow POSIX blindly, it's doubtful that rm should remove the file in this particular case, as the longstanding tradition is that plain "rm" does not remove unwriteable files without more confirmation. Since you know about "rm -f" I suggest using that (that's what everyone else does...).
bug#45700: rm should not prompt if ! isatty(2)
On 1/6/21 10:56 AM, John Wiersba via GNU coreutils Bug Reports wrote: $ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove write-protected regular empty file 'asdf'? # should*not* prompt If the prompt cannot be seen, then it can't be properly answered, so there is no point in prompting and consequently leaving the user with a hanging command and no way to know what's being expected of them. Instead rm should attempt to remove the file and succeed or fail based on the result. POSIX requires the current behavior; see clause 3 in: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html Although GNU rm needn't follow POSIX blindly, it's doubtful that rm should remove the file in this particular case, as the longstanding tradition is that plain "rm" does not remove unwriteable files without more confirmation. Since you know about "rm -f" I suggest using that (that's what everyone else does...).
bug#45700: rm should not prompt if ! isatty(2)
$ /bin/rm --version rm (GNU coreutils) 8.30 $ uname -a Linux xxx 5.4.0-59-generic #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Linuxmint Description: Linux Mint 20 Release: 20 Codename: ulyana $ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove write-protected regular empty file 'asdf'? # should *not* prompt If the prompt cannot be seen, then it can't be properly answered, so there is no point in prompting and consequently leaving the user with a hanging command and no way to know what's being expected of them. Instead rm should attempt to remove the file and succeed or fail based on the result. Same for any other commands (mv, cp) in similar situations. I know about the options -f and --interactive=never, but they shouldn't be needed in this case. Thanks!
bug#45695: Date does not work for dates before 1970
On linux, I can use date +%s --date "31 Dec 1969" The result is -9 A negative number But when I try it on Windows (using GNUWin32) it gives me an error - "invalid date" I downloaded date for windows from this link - http://gnuwin32.sourceforge.net/packages/coreutils.htm Is there any fix for Windows?
