This is a kinda silly question. I've installed Inkscape on my mac (Marvericks OS) following this page http://www.inkscape.org/en/download/mac-os/
I know there is a command line option with inkscape. I tried to type inkscape on Terminal and there is no such command. I'm confused... Does this mean that I need to install the linux version of inkscape in order to use the command line?
I have Inkscape installed in /Applications and running this from a terminal does the trick:
/Applications/Inkscape.app/Contents/MacOS/inkscape --help
Usage: inkscape-bin [OPTIONS...] [FILE...]
Available options:
-V, --version Print the Inkscape version number
... etc.
For ease of use symlink it to /usr/local/bin i.e.:
ln -s /Applications/Inkscape.app/Contents/MacOS/inkscape \
/usr/local/bin/inkscape
In general, on MacOS Inkscape needs to be called with an absolute path, and all files given as arguments should also be full paths. See also:
https://bugs.launchpad.net/inkscape/+bug/1449251
As of 2020, the executable on MacOS is now located at
/Applications/Inkscape.app/Contents/MacOS/inkscape
You can symlink it with:
ln -s /Applications/Inkscape.app/Contents/MacOS/inkscape \
/usr/local/bin/inkscape
More info about command line usage here.
I think some paths and filenames have changed over time and today you should add a symlink in /usr/local/bin to point to the bin directory of inkscape:
sudo ln -s /Applications/Inkscape.app/Contents/Resources/bin/inkscape /usr/local/bin/inkscape
Full credit to #Scott above who has this correct "answer" showing as a comment. This solution allows other subcommands of inkscape to work correctly, whereas creating an alias does not.
Related
I have exuberant tags in my mac. Since, yesterday i am getting this error
ctags: illegal option -- R
usage: ctags [-BFadtuwvx] [-f tagsfile] file ...
I have followed the steps mentoned in this
After following the steps mentioned here i can run ctags -R from command line(iterm)
But when i execute the same command from a .sh (i have a shell script where i run the cscope and ctags command using it) file i get the above error again but not when i run ctags -R from iterm directly.
Any pointers on solving this issue will be really helpfull.
Thanks in advance
So, the above issue seems to be fixed. The issue being that inside the ~/.bash_profile PATH variable should be set correctly. Even though my PATH variable was pointing to /usr/local/bin but /usr/bin appeared ahead of /usr/local/bin , hence somehow the ctags (when run from shell script) was picking up /usr/bin and not /usr/local/bin (which i have set alias to). Just move /usr/local/bin ahead of /usr/bin and it worked fine.
Solution
Type this in terminal:
export PATH="/usr/local/bin:/usr/bin:$PATH"
Along with Neil answer you can simply add alias ctags='/usr/local/bin/ctags' to your .bashrc file.
Under Mac OS 10.10.3, I installed gnu-sed by typing:
brew install gnu-sed --default-names
When I type it again, I get the message:
gnu-sed-4.2.2 already installed
However, even after rebooting the system and restarting Terminal, I still cannot use the GNU version of sed. For example:
echo a | sed ’s_A_X_i’
returns:
bad flag in substitution command 'i'
What should I do to get the GNU version working?
Here are the paths in my $PATH variable.
/Users/WN/-myUnix
/opt/local/bin
/opt/local/sbin
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
/Applications/calibre.app/Contents/MacOS
/opt/ImageMagick/bin
/usr/texbin
I'm sorry if my question seems obvious, but I am learning shell scripting on my own and don't quite understand yet how UNIX programs are installed. Any help to use GNU compliant commands (in this case sed, but soon I'll need others as well) on my Mac without causing damage or unnecessary clutter would be greatly appreciated.
Note (2019):
The --with-default-names option is removed since January 2019, so now that option is not available anymore.
When installing, Homebrew instructs on how to adapt the path, if one wants to use sed without the g prefix.
You already have the gnu-sed installed without the --with-default-names option.
With --with-default-names option it installs sed to /usr/local/bin/
Without that option it installs gsed
So in your case what you gotta do is:
$ brew uninstall gnu-sed
$ brew install gnu-sed --with-default-names
Update path if needed...
$ echo $PATH | grep -q '/usr/local/bin'; [ $? -ne 0 ] && export PATH=/usr/local/bin:$PATH
$ echo a | sed 's_A_X_i'
or use gsed as others suggested.
When you install the GNU version of sed for Mac OS X using:
$ brew install gnu-sed
The program that you use is gsed.
So for example:
$ echo "Calimero is a little chicken" > test
$ cat test
Calimero is a little chicken
$ gsed -i "s/little/big/g" test
$ cat test
Calimero is a big chicken
Also, to compliment the use of GNU command tools on Mac OS X, there is a nice blog post here to get the tools from linux:
Install and use GNU command line tools on Mac OS/OS X
$ brew install gnu-sed
$ export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
With these two commands gnu-sed works properly
The sed that ships with OS X is in /usr/bin.
The sed that homebrew installs is in /usr/local/bin.
If you prefer to use the homebrew one, you have two options:
Option 1
Every time you want to use homebrew sed, type
/usr/local/bin/sed
or, preferably
Option 2
Move /usr/local/bin/ ahead (i.e. before) /usr/bin in your PATH in your login profile, like this
export PATH=/usr/local/bin:<other places>
If you need to use gnu-sed command with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc. Just use the following command in your bash or terminal.
export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
--with-default-names didn't work for me on Mac OS X 10.14.2 so I created a symlink named sed to gsed higher in the $PATH
I also created a symlink named sed.1 to the gsed.1 manpage higher in the $MANPATH so man would access the gsed manpage instead of the default sed manpage
this export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
is only valid per terminal SESSIOn as soon as you restart its GONE ( Mojave )
Since the --with-default-names option was removed in Jan. 2019, my hack solution is:
# hack to override mac tools with homebrew versions (ls, sed, etc)
for p in `find "${HOMEBREW_PREFIX}" -type d -name gnubin` ; do
export PATH="${p}:${PATH}"
done
which is a little slow (crawling the dir every login) but works without forcing me to modify my .bashrc for every gnu tool I happen to install with brew.
A slightly faster way to do what #pjz suggests is the following:
for p in $(ls -d ${HOMEBREW_PREFIX:-/usr/local}/Cellar/*/*/libexec/gnubin); do
export PATH="${p}:${PATH}"
done
Of course this assumes every GNU package in brew will always have the same level of directories to get to gnubin.
Alternatively, you can speed up find by adding the -maxdepth 4 flag before -type d to reduce how far it has to do into directories.
When running brew install gnu-sed on latest homebrew it reports at the end:
==> Caveats
GNU "sed" has been installed as "gsed".
If you need to use it as "sed", you can add a "gnubin" directory
to your PATH from your bashrc like:
PATH="/opt/homebrew/opt/gnu-sed/libexec/gnubin:$PATH"
gnu-sed installs by default as gsed. However, if you look in /opt/homebrew/opt/gnu-sed/libexec/gnubi you'll find a sed command. So following the above instructions to update the path should mean sed runs gnu-sed.
I'm running OSX Mavericks and have installed Macports. I installed gcc via Macports which is working fine. However when I type man gcc I only get:
No manual entry for gcc
I was told I need to add the following to my .bash_profile
export MANPATH=/opt/local/share/man:$MANPATH
which I have done with no effect. Does Macports actually install the corresponding man pages? The man page for the 'port' command works fine as well as other preinstalled tools like clang.
Any help? Cheers.
What the man command looking for is the file 'gcc.1.gz' instead.
You may simply create the symbolic link under the folder /opt/local/share/man/man1
sudo ln -s g++-mp-4.8.1.gz gcc.1.gz
I also did the same for g++.1.gz and c++.1.gz.
I've been having the same problem.
I'm not sure how macports sets the manpath or how to correctly change it in os x for that matter.
But if you do man --path you can see what the path is set to. On mine I see /opt/local/share/man is first.
If I then look for a gcc man page with find it shows me that there is in fact a man page in there
$ find /opt/local/share/man -name "*gcc*"
/opt/local/share/man/man1/gcc-mp-4.8.1.gz
So then I tried man gcc-mp-4.8.1 but that also didn't work.
In the end, it works if you just put the full path when calling man.
This works:
man /opt/local/share/man/man1/g++-mp-4.8.1.gz
Kind of crappy to have to put in the whole path but at least you can see it if you need to.
Putting export MANPATH=/opt/local/share/man:$MANPATH in your .bash_profile is correct, but it will only take effect on new terminals.
I want to create a command line executable which will spawn an emacs window/application.
I searched on the internet and found that the emacs shipped with Mac is not supported in X11 window So, I downloaded the latest emacs from http://emacsformacosx.com/ and installed it in my mac.Then I go to the /usr/bin directory and create a symbolic link like this:
sudo ln /Applications/Emacs.app/Contents/MacOS/Emacs xemacs
when I run this symblolic link by ./xemacs it says(. means /usr/bin):
Warning: arch-dependent data dir
(/Users/david/src/emacs-dev/ftp-versions/emacs-24.2/nextstep/Emacs.app/Contents/MacOS//libexec/emacs/24.2/x86_64-apple-darwin/)
does not exist. Warning: arch-independent data dir
(/Users/david/src/emacs-dev/ftp-versions/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/)
does not exist. Error: charsets directory not found:
/Users/david/src/emacs-dev/ftp-versions/emacs-24.2/nextstep/Emacs.app/Contents/Resources/share/emacs/24.2/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!
But if I run the Emacs binary in directory /Applications/Emacs.app/Contents/MacOS/ it starts the application without any error.
Any one knows how to solve this problem?
Up to this point I think the best way is to create an executable script under /usr/bin which will execute the binary file /Applications/Emacs.app/Contents/MacOS/Emacs. The reason I didn't use "open" command is that I need to use some Emacs binary arguments. Compared to "open" this method can spawn multiple instance of emacs.
The script is :
#! /bin/sh
/Applications/Emacs.app/Contents/MacOS/Emacs "$#"
Then make it executable by doing chmod +x script.sh
then make the symlink
ln -s "/usr/local/bin/script.sh" /usr/local/bin/xemacs
You could use an alias: alias emacs="open -a Emacs --args <youroptions>.
The option --args allows you to pass options directly to emacs (e.g., -q avoids the evaluation of the init script).
I have the latest textmate installed in Applications, the executable is here -
/Applications/TextMate.app/Contents/MacOS/TextMate
I can launch TextMate OK as normal from the icon in Applications
To be able to run from within shell (I use ZSH), I added a symbolic link in /usr/local/bin like so -
sudo ln -s /Applications/TextMate.app/Contents/MacOS/TextMate /usr/local/bin/mate
But I try to run mate from shell, I'm getting the following -
mate[22695:8403] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting
Perhaps I've installed textmate wrong?
You need to symlink the 'mate' CLI, not the TextMate file.
sudo ln -s /Applications/TextMate.app/Contents/Resources/mate /usr/local/bin/mate
I agree with #shellter but…
I don't know if it works in zsh but TextMate has its own CLI wrapper (mate) that you can install from Preferences -> Terminal. It has worked well for years and is very convenient:
Usage: mate [-awl<number>rdnhv] [file ...]
Options:
-a, --async Do not wait for file to be closed by TextMate.
-w, --wait Wait for file to be closed by TextMate.
-l, --line <number> Place caret on line <number> after loading file.
-r, --recent Add file to Open Recent menu.
-d, --change-dir Change TextMates working directory to that of the file.
-n, --no-reactivation After edit with -w, do not re-activate the calling app.
-h, --help Show this information.
-v, --version Print version information.
If multiple files are given, a project is created consisting of these
files, -a is then default and -w will be ignored (e.g. "mate *.tex").
By default mate will not wait for the file to be closed
except when used as filter:
ls *.tex|mate|sh -w implied
mate -|cat -n -w implied (read from stdin)
An exception is made if the command is started as something which ends
with "_wait". So to have a command with --wait as default, you can
create a symbolic link like this:
ln -s mate mate_wait
Another cheap option would be to add an alias to whatever ~/.*rc file zsh executes at startup similar to this one for bash:
alias mate='open -a textmate'