Date seems to work differenty when run as part of a .bat file compared to cmd window. In cmd, date +%F returns exactly what it should (2005-05-17). The exact command in a .bat file returns a literal F. Would greatly appreciate a hand with this. Have tried every permutation of the command I can think of to no avail.
date is also an internal MS-Windows command; therefore date from coreutils is also installed as gdate (similarly for echo, mkdir, rmdir). Alternatively, quote the full path of date.
can we get find installed as gfind? since find is also a windows utility? Should I enter that as a bug?
Yes, this will be the case with the next release of Findutils. No need to enter a bug report.
I did specify the full path in both cases (script and cmd). date is giving different results depending on whether the same, fully qualified command is run from cmd or the script. I was thinking of submitting it as a bug, but I wanted to first see if anyone could attribute this behavior to some XP thing or anything external to date itself. I'll keep the gdate thing in mind though. Thanks.
You might need to escape the % sign.
How do you escape anything in cmd.exe? The stupid thing insists on using the escape character as a directory separator.
You may need to quote the format spec, with double quotes, or you may need to say +%%F, because cmd.exe expects a variable expansion to follow a single %, (although that should really be %F% for a variable called F).
Best advice is to ditch cmd.exe altogether, and use a decent shell, such as the sh.exe included in MSYS, from MinGW.org, or Cygwin's bash.exe; (both are actually bash).
I tried single quotes, double quotes, \, and a couple other things without success. I forgot to try %%. I've used that one in the past (for command), didn't think of it. When I get a chance, I'll try that. I did find a workaround. I'm using date with no arguments, piping the output to cut, to get the result I wanted. Thanks for the suggestion. I'll send an update when I get a chance to test %%.
We have a winner! %%F produced the right result in the .bat file. Thanks for the help.
>I did specify the full path in both cases (script and cmd). >date is giving different results depending on whether the > >same, fully qualified command is run from cmd or the >script. I was thinking of submitting it as a bug, but I wanted >to first see if anyone could attribute this behavior to some >XP thing or anything external to date itself. I'll keep the
> gdate thing in mind though. Thanks
date is an internal command in cmd no matter if you give the full path or not. It won't work.
You may rename it as gdate or use bash, or Ch shell (C compatible shell) from http://www.softintegration.com/docs/ch/shell/
I am definitely getting the GNU date. Although I was having trouble getting it to give me the results I expected, the date that was being executed was definitly doing things the Windows version doesn't have a clue about. Fully qualifying the path does get to the right binary.
Of course it does.
The OP who suggested otherwise is clearly misinformed. With MS-DOS 2.x, there was no easy way to invoke an external command called date', (short of patching command.com), because you weren't allowed to specify a fully qualified path, and any valid extension, if specified, was always ignored, so evendate.exe' matched the builtin `date'. That got fixed in MS-DOS 3.00, which did allow a command to be specified by a fully qualified path, and any command so specified would bypass any attempt to match the builtin names; (however, it still wasn't sufficient to simply add an extension, as the parser removed it before looking for a match).
date', (short of patching command.com), because you weren't allowed to specify a fully qualified path, and any valid extension, if specified, was always ignored, so even
MS-Windows cmd.exe syntax is based on the legacy of MS-DOS 6.2, and this convention applies equally in all Windows versions today -- any command specified by a fully qualified path must invoke an external command, as no builtin can ever match the path name.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.