I am trying to configure dymola.mos file, here is an example of changing directory, but when I activate Dymola, it seems the working directory doesn't change at all, even though the log shows Dymola run the script.
My question is:
How could I make the cd command work in the dymola.mos file?
I assume you have activated the option Save startup directory. You can check this with the flag Advanced.StartupDirectory, which will be either 1 or 2. You can simply turn that off or follow the steps below.
From your command log we see that:
Dymola first executes the script <install-path/insert/dymola.mos
Then it restores the settings stored in setup.dymx
Hence the settings in setup.dymx override your working directory.
Instead of using <install-path/insert/dymola.mos you should use a custom .mos script, which is passed as first argument to dymola.exe on startup. This will always be executed last.
Example for Windows
Create the file startup.mos somewhere, e.g. in C:\dymola\startup.mos
Create a shortcut to Dymola.exe, (for Dymola 2021x: C:\Program Files\Dymola 2021x\bin64\Dymola.exe)
Add the .mos script as argument in the Target field in the properties of the shortcut. The result will be:
"C:\Program Files\Dymola 2021x\bin64\Dymola.exe" "C:\dymola\startup.mos"
Related
I installed an application named lqns in the path: /home/robb/Research/dist/lqns-6.2/lqns (lqns is a folder containing the executable lqns). I want the program to be executed in command line simply calling lqns in the shell, I solved this adding to the file ~/.bashrc the line:
export PATH=$PATH:/home/robb/Research/dist/lqns-6.2/lqns
And it works with no issue. I am now trying to execute this program inside a Matlab script, running:
[status, ~] = system("lqns " + filename, '-echo');
Where filename is the path of an input file. I get the error message:
/bin/bash: line 1: lqns: command not found
Running the exact same command with the shell I get no error: the program runs with no problem generating the relative output.
Running getenv('PATH'); in Matlab and printenv PATH on my OS shell I indeed get two different results: Matlab does't have the path to lqns. I even tried editing manually the files /etc/environment, /etc/bash.bashrc and /root/.bashrc, with no result. How can I solve this issue?
you need to launch matlab by typing matlab in a terminal, not by double clicking on its shortcut from your desktop. (or even typing ./matlab in a terminal from your desktop)
it's up to the operating system to determine what double clicking does, and it's not guaranteed to execute most of your shell initialization scripts (or even launch it from the correct shell to begin with).
more info at Why are environment variables not resolved when double-clicking .desktop file?
This question already has an answer here:
Wrong path set and now .bashrc throws errors [duplicate]
(1 answer)
Closed 6 years ago.
I put an invalid path into my bashrc and now my terminal doesn't work. I've deleted my bash_profile as well as my bashrc and I still can't get it to work.
Every command I use in terminal gives me the error:
sh: parse_git_branch: command not found
This was something I had in my bash_profile for git autocompletion. The problem is once I've deleted the files using /bin/rm <file>, I can't apply my changes with source ~/.bash_profile because it's giving me errors. I've looked at this question, and this question, but I still am having no luck.
How can I fix my command line after breaking things like this?
You can export a correct PATH in your current session using a command similar to :
export PATH=/usr/local/bin:/usr/bin:/bin
After using this, you should be able to source your bashrc.
You can always change your path right on the command line for the rest of the current shell session: PATH="/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:"
Exporting the PATH won't solve your problem. It will only export the value of PATH to child shells/processes. This only achieves the same thing as resetting/changing the PATH variable from the command-line (as shown above), because your scope is limited to the current shell process (and its children) while you are working within that shell environment (working from the command-line). If you open a new terminal (start a new login shell, which is a parent process), bash will still be trying to read from the resource files (.bash_profile and .bashrc), which no longer exist.
So, we need to be able to widen our scope and tell bash that we want to make changes for all future bashes (shell processes--new shells, shells within shells, etc.), and the way that is done is by writing those statements in the resource files.
Once you set your PATH there, every shell session will spawn with those resources (all the aliases, commands, variables, and functions stored in those files), loaded, regardless of whether you export it or not, since each shell process will always consult those files before it does anything else (so they effectively pre-emptively import what you are trying to export to them).
bash is like any other script or program. You took away all its inputs and pointers and shortcuts, and now its just been made pretty dumb, so you've got to be explicit with everything you do till you can teach it where to look for stuff (give it a PATH to search) and shorten your conversations with it.
If you don't have a backup of your .bash_profile, here's one that you can use:
# This loads in the configuration in .bashrc
# Put all configuration in there!
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
And here's a .bashrc that can get you started:
export PATH="/bin:/sbin:/usr/local/bin:/usr/bin:/usr/sbin:"
I have changed the shell key in windows registry to gain custom shell (Kiosk usage):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon]
I set shell key to a batch file which runs two applications as below:
start "myFirstAppTitle" "myAppPath\myApp1.exe"
start "mySecondAppTitle" "myAppPath\myApp2.exe"
Each application runs but the second application which needs some files to be excuted throws an error which says could not find dependency files. whereas the dependency files are adjoining to the exe file and the mentioned app works fine, when starts from startup.
Meanwhile when i run the batch file manually it rusn fine.
I added the PATH command to the batch file but it did't work too.
Change the batch file to this:
set PATH=%PATH%;C:\MyAppPath
start "myFirstAppTitle" "myApp1.exe"
start "mySecondAppTitle" "myApp2.exe"
If you start executables without an absolute path, the path is relative to the current working directory. Also, when you specify an executable with a relative path, %PATH% is not searched for a matching subfolder with a matching executable.
Since the script worked when you manually started it, your working directory probably was C:\. However, when run at logon as a replacement shell, the working directory is most likely "%SystemRoot%\system32".
The problem solved strangely, i removed the title parameter of start command and it worked. In fact i used start command this fashion:
set PATH=%PATH%;C:\MyAppPath
start myapp.exe
start myapp2.exe
Using Windows Workflow in TFS2010, I set up a PS script to run at end of build process. Followed example in http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx to a T and it appears correct in Process section of build definition. However, no matter what I set arg to the dir path of script, the result is always...
The term '.\DataServiceCpy.ps1' is not recognized as the name of a cmdlet, func
tion, script file, or operable program. Check the spelling of the name, or if a
path was included, verify that the path is correct and try again.
I've tried 10 variations of the path. I enabled PS scripts to run on build server and I can run the script successfully from cmd prompt.
Anything obvious that I am overlooking?
many thanks...
In TFS 2013 (not sure for others) exists RunScript activity which is placed into "Team Foundation Build Activities" in Toolbox. I prefer that activity when I want to execute some custom script.
To use this you need to first create arguments (at least one for script path)! To create arguments follow this post.
After you created argument for script path you need to navigate yourself to "Metadata" argument on arguments tab. Add your created argument and also add following statement in "Editor" field: Microsoft.TeamFoundation.Build.Controls.ServerFileBrowserEditor, Microsoft.TeamFoundation.Build.Controls
After that go to "Properties" on RunScript activity and into FilePath insert following statement: AdvancedBuildSettings.GetValue(Of String)("PUT_HERE_YOUR_ARGUMENT_NAME", String.Empty)
Note that you need to insert in last statement exactly name of your argument which you created for script path.
After you are done:
check in your changes;
go to build definition "Process" tab and press "Refresh" button in "Build process template" section;
These steps will allows you to browse your source control and choose your script which you want without providing path.
If you don't need to insert new activity, you can just modify old arguments.
I did it the same way using the same blog and it worked for me. The only difference that I see is that my Powershell script lives in the solution/project folder and in the build definition I specify the powershell script using a relative path. Having a relative path works well with ConvertWorkspaceItem activity. You may want to check (output) the file path that you get after your ConverntWorkspaceItem activity to see if that is the right path.
I hope that helps.
I have a executable that when double clicked opens in a command line window.
Now there is a input file (i.e named "sphere_15000.inp") in the same directory where the executable apame_win64.exe is located. So we can inter the file name in the command line.
The question is how this can be done from mathematica front end? With the RunThrough command I tried to do it with no avail.
RunThrough["Executable Location", "sphere_15000"]
Do I need to put this file location in my Windows 7 environment path variable? Hope for some suggestion in this regard.
UPDATE
Found a solution to my problem.
First set the Mathematica directory to the folder where the executable is located.
path="C:\Users\FlowCrusher\Desktop\CUSP solver\Apame_build_2011_01_09\solver";
SetDirectory[path];
Then use the following style of input.
Run["\"\"apame_win64.exe\" \"input\"\""]
Here "apame_win64.exe" is the executable one want to run and "input" is the input file for the executable. This solves the problem. But a new item in the wishlist.
Is there a way to hide the console window in the background?
Here is how it looks on my screen.
As Chris suggested if we use minimized console in the Run command we get a minimized window but the program does not execute.
I hope that a solution exists.
BR
Yes, you might put the folder of you executable into the Path variable, or provide the full path name.
However, RunThrough seems to have been superseeded (on Windows) by
Import["!command ","Text"], which will execute command and read the comaand line output into Matheamtica as a string.
E.g.:
Export["testit.txt", "bla", "Text"];
Import["!dir" <> " testit* > dir.log", "Text"];
FilePrint["dir.log"]
--
Otherwise, I also had good results in the past using NETLink (not sure if WScript.shell
still works on Windows7/8 or if one should use something else).
Emulating Run (RunThrough is not really needed I think):
Run2[cmd_String] := Module[{shell},
Switch[$OperatingSystem,
"Windows",
Needs["NETLink`"];
shell = NETLink`CreateCOMObject["WScript.shell"];
shell # run[cmd,0,True],
"Unix",
Run # cmd,
"MacOSX",
Run # cmd ] ];
Can you run your application with input from a basic command window instead of the application console? This might be the form of command you would need:
apame_win64 -input sphere_15000.inp
or simply
apame_win64 sphere_15000.inp
You can probably check the available switches by running apame_win64 -help
A multi-part command can be run from Mathematica, e.g.
Run["type c:\\temp\\test.txt"]
Alternatively, also returning output to the Mathematica session:
ReadList["!type c:\\temp\\test.txt", String]
I landed here wanting to run abaqus command line on windows.
The solutions provided here worked out for me (Windows 7, Mathematica 9):
SetDirectory#path;
Run["start /min abaqus job=" <> fileName <> " interactive ask_delete=OFF >> log.txt"]
(Here the abaqus option ask_delete=OFF overwrites an existing simulation results and the >> redirects all the output to a file)
I think, minimizing the window did not run in your case since the executable throws open that window. In that case, this might be of some help