On Wed, 28 Jun 2023 18:11:30 +0200, R.Wieser wrote:
Stan,
In other words, "/D" was ignored and %AHKDATA% was taken as the
command.
No, I don't think that that "/D" was ignored. It just saw an empty path, ended by the space (don't know how the "start" command responds to that, but it might just refuse to try to set an empty "working directory" path). The next argument, in your case the (contents of) "%AHKDATA%" was than - rightfully so - taken as the command and the last two as its arguments.
Your explanation makes sense.
You might want to enter "start /?" on the commandline and see what it thinks how it should be called. In my case it says "[/Dpath]". Mind you, no space after the "/D".
I should have mentioned that I checked syntax not only via Google but
by "start /?" on the command line. "start /?" has "/D path", with
space, in the syntax, matching the syntax guide on Microsoft's site.
So it appears that the version of /D in "start/?" works from command
line and from batch file initiated by the user, but not from batch
file initiated by Windows at startup.
Though in my case following the "/D" with some (white)space works from both the commandline and a batchfile started from that commandline. Than again, I'm running a bit older version of Windows ...
Windows 10 here, 10.0.19044.3086 specifically.
It worked for me in the command line, and in a batch file I ran by double-clicking the shortcut I created in the Startup folder under
the Start Menu. The very same batch file gave the bad behavior when
run by Windows at login time: it displayed the folder that %AHKDATA%
points to instead of running AutoHotkey).
I tested the above command in a command prompt, and it worked just
as intended.
It might have worked as intended, but not as you thought it did (there is a big difference between those two).
I understand: hence my question. :-)
Assuming that your "start" commands "/D" considers the argument terminated
on a (white)space than you should have had the same "%AHKDATA% was taken as the command" problem there too. The only reason I can think of that that didn't happen is that %AHKDATA% variable didn't contain a path, but just (white)space (and was thus skipped).
No, it was a valid path, F:\ORS\CODE\AUTOHOTKEY. And the variable
itself was set in the Registry, not on the command line. A later
command in the batch file, %KEEPASS%, was set in the same way but
with path _and_ program, and that one was executed, so environment
variables must have been populated by the time the batch file was run
at startup.
... At least, in my OS an non-existing environment variable stays as-is in the command (it can't be replaced by its contents because it doesn't exist). If that has changed in Win10 and non-existing environment variables get scrubbed from the command than not (yet) having set that environment
variable would ofcourse give the same effect.
Seems to be the same in Windows 10: "echo %XYZ%" at the command line
echoes %XYZ% with the percent signs. But that can't be the issue
here, since this .CMD file did work as expected when I ran it in the
two ways I described above, just not when Windows ran it at startup.
%AHKDATA% was indeed defined, and correctly. If it was an issue of
environment variables not being populated till a later time in
startup, then the %KEEPASS% command in the batch file would have
failed the also, but it I know it didn't fail because KeePass started
up normally.
Anyway, thanks for replying. I can't imagine how the /D argument in
the start command would work differently between a batch file run as
part of startup and the same batch file initiated by the user
clicking the shortcut in the Startup folder, but that's what seems to
happen.
I'd feel worse about this if I didn't have a workaround: changing my
AutoHotkey script to make the locations of the #include files
explicit.
--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Shikata ga nai...
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)