Glenn Posts: 99 06/10/2015	Glenn Posts: 99 In a Windows command, it seems that references to relative paths start at the directory containing SyMenu, where as in a Program, references ot relative paths start inside the SyMenu directory. So a Program that might reference ..\..\spw\program.exe doesn't get found when the relative path is copied to a Windows Command, there it has to be ..\spw\program.exe This is a bit confusing. I think the Windows Command uses a more natural expectation of where the relative paths should start from, but I doubt that backwards compatibility would allow either to be changed. Perhaps the manual could better explain the expected starting point for relative paths in each case (and there might be more than these two cases, I've not explored every feature of SyMenu as yet).
	link
Gianluca Administrator Posts: 1274 13/10/2015	Gianluca Administrator Posts: 1274 It seems to me that the "strange" behaviour is instead quite normal. If you use a normal program item (SyProgram) you have a starting folder. Any relative paths must start from there. If you use a Windows Command you could have no program, think about a dir command for example. In this case I decided to start it in the SyMenu root folder instead of the natural folder for the cmd.exe (C:\Windows\System32). If you use a normal console program with a SyItem such as a Windows Command element, IMHO, you are forcing the Windows Command element in a strange direction. Use a normal SyProgram in this case. You are talking about portability among SyProgram and Windows Command but it is a not consistent scenario. I surely can describe better the two root paths.
	link
Glenn Posts: 99 17/11/2015	Glenn Posts: 99 I'm sure you can better describe the fact that there are two different root paths, and what they are. If there were only one, it would be even easier to comprehend as well as to explain. It is true that "." as a path name has different meanings depending on the current directory at the time it is referenced. This is something that people have to deal with all the time. It just seems to me to be a shame that within a single program, SyMenu, the concept of "." has different meanings in different contexts within the program. Surely I agree that C:\Windows\system32 is a pretty useless definition of ".", but in looking for an alternative, consistency with SyProgram would seem quite natural to me. Both SyProgram and Windows Command execute commands. Why should they have different definitions of "."? Is there any benefit to the user? What is that benefit? Having a single definition of "." throughout a particular SyMenu invocation (that of the current directory inherited by SyMenu when it is started) would be very natural to me. But, that would be an incompatible change, at this point. So better documentation would help. Maybe you've updated it already. I was too busy the last 6 weeks to read anything here, but just getting back, and updating my SyMenu installations to the latest versions...
	link
Gianluca Administrator Posts: 1274 17/11/2015	Gianluca Administrator Posts: 1274 I completely agree with you. "." is inconsistent, but there is two benefits in that: portability and ease of use. In a SyWinCommand "." means the root SyMenu folder. This is our starting point. "." has this meaning because you need a fixed starting point over your portable environment not a fixed point in every PC... If you need a fixed point in every PC choose a SyProgram and specify your working directory using a system variable or a fixed path instead. Your are right that if you change the SyMenu root folder the meaning of "." changes too. So the command: "dir ." results in a dir of G:\SyMenu if my removable drive is connected as G: and H:\SyMenu if it is connected as H: More if I launch the same command from another instance of SyMenu located in D:\Portable\SyMenu the resulting dir will be D:\Portable\SyMenu. This is the cost of the SyMenu extreme portability! In this case if you want consistency over portability, use fixed paths or system variables: dir C:\ dir %SystemRoot%\system32 Now let's examine the lack of consistency among SyWinCommand and SyProgram. If you execute a program in a console window you usually are located in the same folder of the program to launch or you have to specify its full or relative path. If I consider the program folder as the starting folder I do only what you are forced to do when you launch the program. I agree that it'll be more consistent if the "." means SyMenu root folder in this case too, but it'll be useless because I don't care to be located in the SyMenu root folder I want the program folder instead. This is the reason for which I choose to manage the two different cases in an "inconsistent" way. I think that the problem arises because you are forcing the initial purpose of the two SyItems. SyWinCommand should be used only for Windows commands, while SyProgram with the console output on, should be used for programs that work in a console. Well I know that you are pushing the SyMenu capability to its bounds in the field of commands and maybe you find a lot of limits for this reason but you have to think in the way SyMenu thinks: it is a portable environment. Not an ordinary approach for a command line environment but a full consistent approach for all the SyMenu features.
	link

---