|
B.Wettengel Posts: 23
30/06/2015
|
Hello Gianluca,
It would be helpful (at least for some of my use cases) if you get the full path where SyMenu is located. So I suggest to
- add another Universal Unit Identifier (e.g. #~:\ ) which will be substituted with the full path of SyMenu, not only the Drive-portion where SyMenu is located.
Why: In portable scenarios you probably know the relative path to SyMenu, but not the portion in front of it. If you need the full path to an object you are not able to specify it.
E.g. SyMenu is located on F:\..AnyFolder..\SyMenu. Assume you have programs located in F:\..AnyFolder..\SyMenu\ProgramFiles\another_prog.exe and you need the path for this program.
You can not specify
#:\\SyMenu\ProgramFiles\another_file.ini, because you don’t know then name of ..AnyFolder.. and therefore will not work. (Especially in network-locations, when different people are involved)
If you had the full path to SyMenu (e.g. #::\) you are able to write #~:\\SyMenu\ProgramFiles\another_file.ini and this will resolve to F:\..AnyFolder..\SyMenu \ProgramFiles\another_file.ini
Note: Sometimes you can overcome this situation by defining Workdirectory, but this doesn’t work on Networkshares with cmd.exe (the workdirectory will be set to c:\windows by cmd.exe!)
What's your opinion?
Greets Andreas
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
30/06/2015
|
Well my opinion is that your idea is fantastic but, are you really sure that every need you have shouldn't be accomplished using the relative path notation?
For example if you have a program located in
F:\AnyFolder\SyMenu\ProgramFiles\prog.exe
or in
\\netShare\SyMenu\ProgramFiles\prog.exe
you can point to the prog.exe easily with the relative path:
.\ProgramFiles\prog.exe
It's a perfectly portable configuration and works on the network shares too.
In the last versions I increased the portability of the WorkingDir and, especially, for the ProgramArgs parameter. Now either support the universal unit identifier and the relative path.
So I ask you to make a real example not resolvable with the relative path notation. In case you find one it's probably a bug and I have to fix it. Otherwise I'll surely implement your #~:\ suggestion.
edited by Gianluca on 01/07/2015
|
|
|
link
|
|
B.Wettengel Posts: 23
30/06/2015
|
I always try to use relativ path, but sometimes I'm forced to use the Full path.
For example: I have PStools installed in ...SyMenu\Programfiles\PSTools\ (some .exe sits there)
I want the following program item:
Pfad: %comspec%
Parms: /Kpushd "%CD%"& (dir /D/on /p *.exe&echo.&echo Type Name of a Tool above!)
This works fine on a physical drive and on a mapped network drive, but NOT with UNC-path, bacause cmd.exe changes work directory to c:\windows. So I want to use
Pfad: %comspec%
Parms: /Kpushd "%#~:\\SyMenu\Programfiles\PSTools"& (dir /D/on /p *.exe&echo.&echo Type Name of a Tool above!)
P.S: this is an example for PSTools, but I use some other Apps which make use of the workingdirectory on a network share. With this new Identifier, I can stay with relative path, no matter where the root is.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
30/06/2015
|
Ok I don't know where the problem is but I quickly check some cases and the relative paths work regularly even when SyMenu entirely resides on a network share.
Let's do an example with a Jar program.
SyMenu reside on a network share, not mapped
\\netShare\SyMenu
The program executable in my case is a jar program so I have to put as a real executable java that is in the network share too.
.\ProgramFiles\JavaRuntimeEnvironment\bin\java.exe
Now my two experiments
1) Explicit Working dir
Program argument: -jar prog.jar
Working directory: .\ProgramFiles\TheJarProgramFolder\
It works
2) Implicit Working dir, explicit path on the program argument
-jar .\ProgramFiles\TheJarProgramFolder\prog.jar
It works
I have never used PSTools but is it possible that if you write your params without the % symbol the relative path starts to work?
Parms: /Kpushd ".\Programfiles\PSTools"
|
|
|
link
|
|
B.Wettengel Posts: 23
01/07/2015
|
You are right, I can use relative path.
After a little bit (or more ;-) playing around, I found out why it did not work and how it works, but I can't tell why it works at all. (in a command window it behaves different?)
Anyway here is what works:
Pfad: %comspec% Parms: /kpushd ".\config" &dir /B&echo Type Exit!
and what doesn't: (one space in front of &dir was missing)
Pfad: %comspec% Parms: /kpushd ".\config"&dir /B&echo Type Exit!
Thanks a lot, your tip pushed me in the right direction.
P.S: I used a short example here for easier reproduction, which in real world makes not much sense!
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
01/07/2015
|
I'm happy for the resolution.
My idea regarding the different behaviour from SyMenu and Windows Command is this. When you use a relative path such as ".\config" SyMenu, at run time, resolves and replaces it with the corresponding full path for example
".\config" -> \\netshare\SyMenu\ProgramFiles\config
I fear that the replace feature removes the double quotes so that your
".\config"&dir
that regularly works on a command windows because it is solved as
"\\netshare\SyMenu\ProgramFiles\config"&dir
in SyMenu becomes
\\netshare\SyMenu\ProgramFiles\config&dir
which is no more an existing path because, lacking the double quotes, the last folder name is config&dir.
Instead your
".\config" &dir
with the space separator becomes
\\netshare\SyMenu\ProgramFiles\config &dir
which works because the first part is an existing path and &dir is a normal parameter.
A techical digression.
To make everything works, naturally I have to convert the full path again in the DOS 8.3 short format so that a folder with a space inside its name works the same even without the double quotes.
For example "Program Files (x86)" become Progra~1. Don't ask me why I have to remove the double quotes...
Last observation.
Are you sure that you first command, the one without the space ("\config"&dir), is formally correct?
I understand that it works the same in the command window but it seems to me very strange that the documentation allows you to write two parameters without at least a space separator. In my opinion it has worked by accident until now.
|
|
|
link
|
|
B.Wettengel Posts: 23
02/07/2015
|
thank you for your detailed answer.
@your technical digression:
double quotes are sometimes difficult to handle, especially with cmd.exe. Because you convert long to short-names, I think this is why some things work, even with filenames containing spaces.
Only a thought: windows can be configured not to use short-names, maybe you have issues then. I didn't try that with SyMenu, but had troubles with other Apps.
@last observation:
yes I am sure. "&"-character is used to seperate commands on one line. In batch-script you would normaly put each command in a separate line. If I run cmd.exe from within SyMenu there is only one line for parameter. So I'm forced to use this in order to execute more then one command (without writing an extra script).
The different behavior is another story. You can try it. Open a command window and type
cmd /k pushd c:\Symenu\config & dir
what it does:
the parser sees the &-char and executes first command (cmd /k pushd c:\Symenu\config). The /K-Options tells him to stay open, so the 2nd command (dir) does not execute until you end the new cmd.exe with exit. Immediate after that the dir will be executed, but on the wrong directory (where you where before pushd). So far OK, but in a SyMenu program item they are executet both and you get the output from the wanted directory.
Because that is what I need, please leave it that way, but I do not understand!
Note: cmd /c pushd c:\Symenu\config & dir will not wotk either, same behaviour as above, but does not wait for exit. (/C-option means execute and exit cmd.exe)
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
03/07/2015
|
B.Wettengel wrote:
Only a thought: windows can be configured not to use short-names, maybe you have issues then.
Oh my God.... I strongly hope that no one disables the short names paths in his system. I not even know that it could be possible.
B.Wettengel wrote:
@last observation[...]
Well your proposal to leave it that way is my favorite :-)
I did an experiment with your example and actually the behaviours of the SyMenu command and Windows command are different.
SyMenu doesn't respect the /k flag probably because the redirection I do doesn't allow to open a different command. In fact what happens behind the scenes is that SyMenu redirects the command to the original Windows command shell, grabs the output and shows it on its own window. Maybe this redirection is allowed only with a single level of cmd execution.
Anyway I thought that for every borderline use of the Windows command, when the SyMenu command item is not suitable for that, you have the chance to use the original Windows command. So I tried to configure a Program item (not a Windows command item), filling the path with "cmd.exe" and the program argument with your command. I don't check the Output command flag so the original Windows command is used.
But even in this configuration the behaviour is quite different than the command directly put in the orginal Windows command shell: the pause /k is not observed, the new cmd is not opened.
I think that I'll go deep with that configuration (Program item that launches the cmd.exe) and try to solve at least this problem.
I don't think that a change with this element will break your scripts in any way because you are using the Windows command items which work in a different way.
|
|
|
link
|
|
B.Wettengel Posts: 23
08/07/2015
|
I think I found it. At least I con do it in a ordinary command-window
the point is quoting. If you use cmd /k "pushd c:\Symenu\config & dir" then it works. So I guess SyMenu does the quoting by itself. (I used a Program-Item and %comspec% for path and /k pushd c:\Symenu\config & dir as parameter).
It's so easy, if you see it 
|
|
|
link
|