I'm trying to install Uppaal on my Mac. I have Catalina installed and I am aware of the workaround posted on here to do with authorisation and have done this.
But when I run the Uppaal script I get an error saying
Error: Unable to access jarfile ./uppaal.jar
I can't figure out what the problem is or how to get around it. Java is up to date.
Help please, I need this for a uni assignment
It seems that UPPAAL will give the above error, if run it from the GUI from a path containing a space.
I will report this to the development team, until they are able to fix it one of the following workaround:
move the files to a path not containing any spaces (NB: the full path must not contain any spaces)
open the uppaal batch file(e.g. by TextEditor) and add this command to the top of it:
cd "$(dirname "$0")"
Just encountered the same issue. Instead of adding cd "$(dirname "$0")" to the uppaal bash script, which is a bit intrusive, I changed line:
HERE=$(dirname "$(readlink -e $0)")
to:
HERE=$(realpath -s "$(dirname "$0")")
This does not change the current directory at time of invocation. Instead it turns the (wrong) relative path of uppaal.jar to an absolute path.
Related
-bash: export: /Users/deboadebayo/Desktop/Coding/:/opt/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.8/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin':
not a valid identifier
The above message is the error message I receive every time I open my terminal. I did create a backup of my bash profile. But essentially now I can no longer navigate anywhere I want to go using command line requests.
Any help would be much appreciated
If you have a backup, use an absolute path to the mv and cp commands to rename your broken file and restore the backup, both without depending on path lookup.
/bin/mv .bash_profile .bash_profile.broken
/bin/cp .bash_profile.backup .bash_profile
Close the current terminal window and open a new one, which should use your working, original .bash_profile to initialize PATH. Now you try to make the correct modification to your PATH.
oops. The easiest way to fix it would be to launch an editor with an absolute path. $PATH only specifies the locations in which the shell will search if told to execute a program relative (or no) path specified. The which program can search the path and shows the first executable found:
$ which vim
/usr/bin/vim
So if you're a vim user, you should be able to run /usr/bin/vim at the command line, and the path won't be relevant. Then you can fix your file in the editor. Looks like my osx machine also has nano if you'd prefer that editor. I don't think I installed it so it probably came shipped with osx I'm guessing:
$ which nano
/usr/bin/nano
If you want to revert to your backup, use cp, but specify it from its absolute position, /bin/cp:
$ /bin/cp first.txt second.txt
Obviously you'll want to change the file names on that one for it to work for you.
I'm trying to write a bash script to install the latest texlive on a server (part of provisioning in Vagrant). Texlive comes packaged as install-tl-unx.tar.gz, but when unpacked, the resulting directory name includes the date of the last upgrade, e.g. install-tl-20161129. Since I can't predict the date portion of the directory name, how can I cd into it? Is there a script equivalent of hitting tab? I searched but couldn't find anything applicable.
I suggest to use globbing:
cd install-tl-*
or to catch 8 digits with globbing:
cd install-tl-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]
I'm doing some Android development and want to access the command line tools from anywhere.
There wasn't an existing .bash_profile file in my home directory so I created one and added the following line:
export PATH="/Users/Me/desktop/Android/Android SDK bundle/sdk/platform-tools"
I can now access the Android tools from terminal, however the ls command has stopped working, though cd still works. I get
-bash: ls: command not found
What should I do to get it to work again (and why has ls stopped working but cd still works?).
Try:
export PATH=$PATH:"/Users/Me/desktop/Android/Android SDK bundle/sdk/platform-tools"
It will append to the current PATH your sdk directory.
As for the later question, it stopped working because you overwritten your PATH variable, so bash can't find your binaries. However cdis a builtin command (http://linux.about.com/library/cmd/blcmdl1_builtin.htm) it doesn't need a path to be located and executed.
I use a bash script to install an app on Mac OS X "Lion". First I copy the app bundle into place, then attempt to install postgres into the app bundle. The data path for the postgres db needs to be in "~/Library/Application Support/myappfolder/data/".
Now the problem (appears to be) that the script stumbles because the OS says the path is not found. Backing up the path names I get to "~/Library/" and it still fails. The script is run with admin privileges.
To put this another way, from the terminal, this works:
me: cd ~/Library
but this does not:
me: mydir="~/Library/"
me: cd $mydir
I know things have changed in 10.7, but I haven't found the answer at the dev center yet.
I don't think this is Lion-specific. When you use quote marks, you are causing the ~ character to be treated literally, instead of as an alias for $HOME. So it's looking for an actual directory with a tilde in the name, which doesn't exist.
Try using mydir="$HOME/Library" instead to see if that fixes the problem.
This actually doesn't work in 10.5, either, so I don't think it's a Lion specific problem. Something like this will always work, though:
eval "cd $mydir"
so, I just downloaded the latest Version of chipmunk, and when I run the iphonestatic.command from finder I get the following output in my Command Line
Last login: Wed Oct 26 22:15:59 on ttys001
PS1:~ Thermo$ /Users/Thermo/Desktop/Programs\ software/Software/iphonestatic.command ; exit;
usage: dirname path
Build settings from command line:
SDKROOT = iphoneos4.3
xcodebuild: error: 'Chipmunk6.xcodeproj' does not exist.
logout
I can't get the script to build the proper files, and have been trying to figure this out for a while,
thanks for any help
Aha! After a stroke of luck I discovered that you could cause that bug by having a space in your path somewhere.
The first line of the script does this to set the working directory to the parent directory of the script when running it from the finder:
cd `dirname $0`
It barfs when you have a space in the path somewhere. Not exactly certain how to fix it... The workaround is easy enough though, just make sure you put it somewhere it won't have a space.
edit: Looks like it just needs multiple sets of parens:
cd "`dirname "$0"`"