OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: arr531 on August 18, 2016, 04:25:04 pm
-
Virtualbox 5.024
OS/2 Warp 4.52 unofficial fixpak 6
Hello all, is it not possible to have environment variable substitution in the Working Directory field for program objects?
For example: the program object for the text editor. If I have the HOME environment variable set to c:\home\adam and I want the Text Editor's Save As dialog box to always open in my home directory is it not possible to just specify %HOME% in the working directory field for the Text editor's program object? I have tried using %HOME% and that doesn't work. I have tried several different permutations but nothing has worked yet. I am beginning to think it just doesn't support variable substitution.
-
Virtualbox 5.024
OS/2 Warp 4.52 unofficial fixpak 6
Hello all, is it not possible to have environment variable substitution in the Working Directory field for program objects?
For example: the program object for the text editor. If I have the HOME environment variable set to c:\home\adam and I want the Text Editor's Save As dialog box to always open in my home directory is it not possible to just specify %HOME% in the working directory field for the Text editor's program object? I have tried using %HOME% and that doesn't work. I have tried several different permutations but nothing has worked yet. I am beginning to think it just doesn't support variable substitution.
The home variable is an import from UNIX and most OS/2 applications do not "see" it unless specifically written to do so, you are meant to explicitly give the program a specific working directory or no working directory at all, only a few Windows ports such as StarOffice require a working directory AFAIK. Remember that the OS/2 UI is built on O-O/CUA principles and sort of expects people to sort "objects" into project folders (real or virtual folders, and actual files and/or shadows) and work from them, the concept of a home tree as in UNIX is counter-intuitive to that way of thinking.
-
I understand that about the HOME variable. I just used that as an example. The question is whether you can have variable substitution in program object's fields or not.
-
Hi adam
I think the answer is no.
I base my answer on the fact that any OS/2 apps that use an installer and create an application program object use the fields for specific purposes:-
Path and file name: the full path to the executable
Parameters: any parameters to pass to the executable
Working directory: the directory where the executable is found
Probably the only field that could use variable substitution is Parameters but then the app needs to understand what it is being given - applications seem to expect some switches and/or a [drive:\path\]filename. The other 2 fields seem fixed in that you are not likely to have an application that moves around your hard drives by itself.
I think variable substitution works on the cmd line. If I am right then a workaround, if needed, could be to create a cmd file to start the app and give the program object the cmd file details with the application icon and name.
I guess your definitive answer will be somewhere in the documents describing the design and implementation of OS/2 but I have no idea where to look...
Regards
Pete
-
No, an automatic env var resolution exists in cmd.exe. PM apps must implement that additionally. The only special vars supported in the parameters entry field of a program object are '%*' and the '%**x' ones.
-
I believe it's a possible work-around to create a wrapper application which does two things: (1) copies the current environment and alters it to include any desired changes, and (2) pass that environment along to a spawned application which inherits the altered environment as per its needs.
A generic app which does this may already exist, and if not one could be written.
Best regards,
Rick C. Hodgin
-
Okay thanks guys, that is the answer I was looking for. I will just have to hard code the path into the apps I want and then hard code the path into the field of the Program object template. It is what it is.