When you create a shortcut to run an application, one of the fields
you can fill in is "Start in", which will be the current directory as
far as the application is concerned.

I have three startup programs that need to run in a specified order:
first AutoHotkey then KeePass, then VeraCrypt. So I created a batch
file to run them. The first line was

start "AutoHotkey" /D %AHKDATA%
"C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk

The %AHKDATA% variable -- defined as F:\ORS\CODE\AUTOHOTKEY --
contains the location of my AutoHotkey script files, and AutoHotkey
needs to run in that folder because Shortkeys.ahk contains several
#include commands. In the start command, /D {path} corresponds to the
"Start in" box in a shortcut.

I tested the above command in a command prompt, and it worked just as
I intended. Then I put it in a batch file, and put a shortcut to that
file in my startup folder. Instead of running AutoHotkey, Windows
popped up an Explorer window on the %AHKDATA% folder. In other words,
"/D" was ignored and %AHKDATA% was taken as the command.

Some googling found Rob Vanderwoude's page on the start command, and
he gives the syntax not as start /D {path} but as start /d{path},
with no space after the /d. I tried that in my batch file --
/d%AHKDATA% -- and it worked at startup!

I can't see any reason why the command parameter should be /d without
a space in a batch file run at startup, but /d with a space in a
command window after startup is complete. But maybe I'm overlooking
something. (There are no spaces or special characters in %AHKDATA% --
it's defined as F:\ORS\CODE\AUTOHOTKEY.)

Can anyone shed any light?

(At this point it's just curiosity. I changed my AutoHotkey script's
#include commands to specify the directory explicitly, so now the
start command doesn't need a /D parameter.)

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On 28.06.2023 07:19, Stan Brown wrote:

> start "AutoHotkey" /D %AHKDATA%
> "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk

Maybe:

start "" "AutoHotkey" /D %AHKDATA%
"C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk

Herbert Kleebauer <klee@unibwm.de> wrote:
> On 28.06.2023 07:19, Stan Brown wrote:
>
>> start "AutoHotkey" /D %AHKDATA%
>> "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk
>
>
> Maybe:
>
> start "" "AutoHotkey" /D %AHKDATA%
> "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk
>
>

Fastest and easiest is to add the folders to the PATH to eliminate
requiring specification in all batches.

--
Zaidy036

On Wed, 28 Jun 2023 08:18:25 +0200, Herbert Kleebauer
wrote:
>
> On 28.06.2023 07:19, Stan Brown wrote:
>
> > start "AutoHotkey" /D %AHKDATA%
> > "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk
>
>
> Maybe:
>
> start "" "AutoHotkey" /D %AHKDATA%
> "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk

Thank you for replying, but it's not clear to me how
that would work at all. One leading double-quoted
parameter is the window title. Two leading quoted
parameters doesn't seem consistent with the published
command syntax.

--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Shikata ga nai...

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.

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".

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 ...

> 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).

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).

.... 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.

I'm afraid you will need to have to do some (further) tests to figure out
what exactly went on.

Regards,
Rudy Wieser

On 28.06.2023 17:16, Stan Brown wrote:
> On Wed, 28 Jun 2023 08:18:25 +0200, Herbert Kleebauer
> wrote:
>>
>> On 28.06.2023 07:19, Stan Brown wrote:
>>
>> > start "AutoHotkey" /D %AHKDATA%
>> > "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk
>>
>>
>> Maybe:
>>
>> start "" "AutoHotkey" /D %AHKDATA%
>> "C:\Program Files\AutoHotkey\AutoHotkey.exe" Shortkeys.ahk
>
> Thank you for replying, but it's not clear to me how
> that would work at all.

Sorry, my fault. Didn't read carefully enough.

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...

Stan,

> 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

Although I could imagine that, its way to unlikely.

As a test you could try to replace the %AHKDATA% variable with its actual
contents and see if you now get the same result. If not than that seems to
indicate that that variable is filled later than you think ...

Regards,
Rudy Wieser

On 6/29/2023 3:07 AM, R.Wieser wrote:
> Stan,
>
>> 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
>
> Although I could imagine that, its way to unlikely.
>
> As a test you could try to replace the %AHKDATA% variable with its actual
> contents and see if you now get the same result. If not than that seems to
> indicate that that variable is filled later than you think ...
>
> Regards,
> Rudy Wieser

Hypothetically speaking, what would happen if
the evaluated %AHKDATA% has a space character in the path ?
Is that whole launch sequence "proofed" against that ?
Or does it need double quotes around it ?

Paul

On Thu, 29 Jun 2023 06:41:50 -0400, Paul wrote:
> Hypothetically speaking, what would happen if
> the evaluated %AHKDATA% has a space character in the path ?
> Is that whole launch sequence "proofed" against that ?
> Or does it need double quotes around it ?
>

I believe it would need double quotes, but it's a moot
point because the value of %AHKDATA% is
F:\ORS\CODE\AUTOHOTKEY

--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Shikata ga nai...

On Thu, 29 Jun 2023 09:07:40 +0200, R.Wieser wrote:
> As a test you could try to replace the %AHKDATA% variable with its actual
> contents and see if you now get the same result. If not than that seems to
> indicate that that variable is filled later than you think ...

Well, I could, but I don't think there's any reason to.
Maybe I didn't explain well last time:

In the same batch file I have a _command_ %KEEPASS% to
open that program. The program does open at login; I
know this because it prompts me for the master
password. Therefore I know that environment variables
are already populated.

(And no, that prompt couldn't be coming from KeePass
opening in a different way. When I wrote the batch file
I removed the other shortcuts from the Startup folder
in the start menu. KeePass's option to start
automaticaly is unchecked.)

--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Shikata ga nai...

Stan,

>> As a test you could try to replace the %AHKDATA% variable with its
>> actual contents and see if you now get the same result.

> Well, I could, but I don't think there's any reason to.

Understood.

You already said that you got it running. I just thought you would be
curious to the reason of your earlier try not working. At least, that is
what your initial post conveyed ...

Regards,
Rudy Wieser

On Thu, 29 Jun 2023 14:54:39 +0200, R.Wieser wrote:
>
> Stan,
>
> >> As a test you could try to replace the %AHKDATA% variable with its
> >> actual contents and see if you now get the same result.
>
> > Well, I could, but I don't think there's any reason to.
>
> Understood.
>
> You already said that you got it running. I just thought you would be
> curious to the reason of your earlier try not working. At least, that is
> what your initial post conveyed ...

I _am_ curious, but "environment variables not populated" is not the
cause. I've explained why, a couple of times,(*) but if you think I'm
wrong please set me straight.

(*) In the same batch file I have a _command_ %KEEPASS% to
open that program. The program does open at login; I
know this because it prompts me for the master
password. Therefore I know that environment variables
are already populated.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan,

> I _am_ curious, but "environment variables not populated" is not
> the cause.

Besides Murphies Law my own experience tells me that just discarding
possiblilites because "that can't ever be it" are a good way to waste lot of
time. :-\

Besides, it would take you ... 5 minutes ?

> In the same batch file I have a _command_ %KEEPASS% to
> open that program. The program does open at login

I read that and I believe you. But to me that /proves/ nothing.

>Therefore I know that environment variables are already populated.

No you don't. You just /assume/ they *all* are.

"Yesterday I checked if my cars left rear tire had enough air in it. It
had, so I assumed the others had too. I was stopped and got a ticket for
three missing tires."

Yeah, thats a joke. But I hope you get my drift there.

Regards,
Rudy Wieser

On Fri, 30 Jun 2023 11:44:23 +0200, R.Wieser wrote:
>
> Stan,
>
> > I _am_ curious, but "environment variables not populated" is not
> > the cause.
>
> Besides Murphies Law my own experience tells me that just discarding
> possiblilites because "that can't ever be it" are a good way to waste lot of
> time. :-\
>
> Besides, it would take you ... 5 minutes ?
>
> > In the same batch file I have a _command_ %KEEPASS% to
> > open that program. The program does open at login
>
> I read that and I believe you. But to me that /proves/ nothing.

Well, it's awfully hard to imagine Windows would populate some user
environment variables, then run a shortcut in the startup folder,
then populate the rest of the user environment variables (or run the
two tasks simultaneously, which would come to the same thing). But
let that pass.

I actually disposed of "environment variables not populated" in my
first post to this thread. It's been so long ago that I forgot about
it till now. :-)

As I reported then, when I used /d%APPDATA%, the batch file worked as
desired _both_ when initiated by double-click on the shortcut _and_
when started by Windows at login. With /D %APPDATA%, it worked
_after_ startup but not _during_. It may be worth pointing out that
Microsoft's own documentation, on the web and in "start /?",
specifies /D with following space, and no warning about batch files
that run at startup.

Unless someone has a better explanation, I'm going to chalk it up to
a weird bug in Windows, that probably never got noticed because,
after all, how many people (A) run batch files that (2) contain start
commands (c) with a directory parameter (iv) at login time?

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...