I am installing gitlab on a mac but this latter is mainly designed for linux os. Following the doc, I have to run this command
curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/init.d/gitlab
What is the mac equivalent of the /etc/init.d folder (I know about the launchd command but I am looking for the mac's equivalent /etc/init.d folder) ?
AFAIK, launchd stores its data primarily in .plist files in /Library/LaunchAgents/ and /Library/LaunchDaemons/, and occasionally in those subdirectories in your home directory. More on those files in this tutorial and this reference.
For your problem specifically, to set launchd up to run gitlab, try converting that init.d script to a .plist file with the links above.
I don't know if you still care about the question or not, but what ryan said is correct. And to directly answer your question, your curl command is trying to download a startup script and put it into your init.d directory. You don't have one, as you are on Mac OS X.
What you need to do is pop that init.d somewhere else that is permanent. Make sure it is chmod +x and test to see if it works manually. (ie. ./init.d)
If it does, you can create a .plist and pop it into /Library/LaunchDaemons/ that will run your init.d file. If your init.d file is as simple as just running an executable, then forget the init.d file entirely, and just have the .plist file run the gitlab executable file directly.
Either way, I think that you should mark Ryan's (or mine as well) answer as Accepted, as it will solve your issue. The only reason I didn't put this as a comment on Ryan's answer is that my explanation was too long for a comment.
For a system with M1, it is stored in /sbin/launchd
It is differentiated with the PID 1
Related
I installed homebrew with brew install wget and when I opened my .bash_profile it was some file I had never seen before full of homebrew's things. My aliases are still working, but I was wondering where I could find them since they're not in the txt file anymore.
I am not familiar with OSX, but I guess your old bash settings could have been backed up somewhere, because your aliases are still working. Try searching for files/directories named "bash*".
you should try using a file recovery program. it is possible the alias is referring to the location on the HDD and that the file still exists, even if the file with that name isn't accessible anymore.
a file recovery program may be a good option.
The current directory on cygwin is home/myuser. I navigated to cygwin and found it has a directory called home/myuser and could not figure out how I would navigate to the desktop. I did not want to add a desktop directory there and I could not navigate above the root folder (cygwin). Any idea on how I could do this?
This is essentially covered in the Cygwin FAQ under "How can I access other drives?". No, you're not trying to access another drive, but you are trying to access a folder outside of the Cygwin tree. As the FAQ item says, Cygwin maps your Windows drives as /cygdrive/<drive-letter>, so your desktop is likely something like /cygdrive/c/Users/<username>/Desktop. Note that the path has changed over the years with various versions of Windows and you didn't specify what version you're running, so it may not be exactly that.
Anyway, what I would do, would be to create a symbolic link to that from my Cygwin home folder. Something like this:
ln -s "/cygdrive/c/Users/<username>/Desktop" Desktop
I put the quotes in because depending on what version of windows you have, this path may include spaces.
You'll probably notice from the FAQ that the Cygwin version of bash accepts DOS-style pathnames, so you can actually do the following:
cd "C:/Users/<username>/Desktop"
But I recommend avoiding such syntax. Not all Cygwin apps understand DOS-style paths, and you'll only end up confusing yourself if you have to try to figure out whether what you're doing will work with a DOS-style path or not. It's best to just use the Unix-style paths for everything when in the Cygwin environment, unless you have a very good reason not to.
Add
cd "/cygdrive/c/Users/<username>/Desktop"
to .bashrc file located in <cygwin install directory>/home/<username>. This will change working directory to desktop every time you open Cygwin terminal.
Wow, let me first say that I've lost count how many answers I've found on this site. You guys are awesome!
So, my first-ever question I'm posting is rather basic so I hope it's not badly received. I did search to find an answer on google as well as here, but did not find an answer.
I just created a console app with code:blocks on linux, compiled it then ran within code:blocks. Works just fine. Then I opened linux bash shell, cd to where the binary was, then just tried running it from there, no dice. A linux buddy of mine came over and told me to try ./ preceeding it. Viola, that worked. I was dumbfounded because I thought ./ was only needed to execute shell scripts. I checked file permissions for the binary built by g++ and they are these: -rwxrwxr-x
I've found other tutorials on building the Hello World application with code:blocks and they also say to execute on the command line using ./
Why is this so? Also, how can I build a console application or any other binary application such that the ./ is not required to execute it? I'm assuming it's possible somehow seeing as the vast majority of the built-in linux commands, such as grep, etc do not require the ./ to execute.
Thanks, guys.
To run an executable on UNIX-like systems, you need to be aware of path resolution. If the path to the executable is not included in the PATH environment variable (and . sometimes isn't), you need to specify it yourself.
By appending . to PATH, like this:
export PATH=$PATH:.
you can run executables from the current working directory without adding ./. Note, however, this may be unsafe in a multi-user system, as other users can provide executables for you to run, in group or world writable directories, without your explicit permission(s).
I am relatively new to Linux and Unix. With the help of the internet I finally figured out how $PATH and aliases in my .bashrc work.
But I really couldn't find anything that describes when to use which.
Let's say I installed Python3.3 in Library/Frameworks and the executable is
/Library/Frameworks/Python.framework/Versions/3.3/bin/python3, but I want to execute python 3.3 just by typing python3 into my terminal.
When I understand it correctly, there are (at least) three methods to achieve this:
1) I modify $PATH in my .bashrc:
export PATH=/Library/Frameworks/Python.framework/Versions/3.3/bin:${PATH}
2) I set an alias in my .bashrc:
alias python3=/Library/Frameworks/Python.framework/Versions/3.3/bin
3) creating a symbolic link (symlink):
ln -s /Library/Frameworks/Python.framework/Versions/3.3/bin /usr/local/bin
What would you say (from your experience) is the "recommended" way?
Putting python3 in your path is the correct way to invoke it anywhere you might find yourself in your filesystem. A symbolic link is the best way to change that command to python and keep your scripts non version dependent (you can run a script that depends on python use the symbolic link and a script that needs python 3.0 specifically use python3, even though on your computer they are the same thing). Symbolic links are still files in your filesystem, so they still need to be in your path.
I only see aliases used when you are trying to create some kind of behavior that is different than the default behavior for a command line utility like an alias for ls that adds -a silently.
Also symbolic links are stored in the filesystem so once created they exist for all other users who log in, while aliases only apply to the logged in user who has defined them. They can also have file permissions applied to them.
Here is a fun article about things you can do to your terminal through your .bash_profile including some great aliases.
First, there is no reason to install Python in a /Library/Frameworks/ directory. My suggestion is that (at least for a beginner) you should not add top level directories like your /Library. If you compile it from source code, you should have built it with a standard ./configure (and it probably goes into /usr/local/)
I don't know well about compiling Python from source code, but most Linux source code gets by default ./configure-d to a /usr/local/ prefix so their binary go into /usr/local/bin/ which is often already by default in your PATH
Some Linux distributions have an /etc/profile which indirectly, if the directory $HOME/bin/ exists, adds it inside your PATH; in that case just adding binaries and scripts (or symbolic links) there is the most simple way.
My general advice is to avoid having a very long or very specific PATH. In particular, adding a directory inside your PATH for each product is IMHO a mistake. See e.g. the directory-variables section of GNU coding standards, and keep your PATH quite short. Personally I add programs only in /usr/local/bin/ (system-wide) or in $HOME/bin/, perhaps as symbolic links (so I don't change my PATH since it already contains both /usr/local/bin/ and $HOME/bin).
By past experience having a very long PATH is a nightmare, and slows down your interactive shells
Thank you all for your explanations.
As I already said, I am pretty new to Unix and Linux. I just wrote an article about those things (aliases, symlinks $PATH) for my blog for other "newbies". I like to write about those things, because they really interest me, and I want to share my experiences - I hope they are helpful to other people, too. Furthermore, it helps me to deepen my understanding if I have to explain things - and it is a good future reference, too!
It would be nice if you could skim over the article very quickly, and if I got some things wrong, I would be very happy about suggestions!
http://scientific-ocean.com/2013/02/17/an-introduction-to-linuxunix-executables-path-aliases-and-symlinks/
I would suggest go for alias which would make it easier for conflicts arising if you different versions of Python. The shell will look up the PATH variable and wherever it matches the executable of Python it will execute it. The alias has to be put in your shell profile like .bash_profile.
I am not sure to ask it here or at serverfault, but it has to do with my script and creating an installer...
I have made a service (linux perl script) and all the configuration files and etc etc.
I would like to make an installer for it so it creates folders/puts files on the right spot, etc.
Now while developing I made a script in the /etc/init.d/ folder called "reliand".
Now when I send all my files, plus the installer to another user and I would copy that file to the same dir on that machine (i know it's same CENTOS) how would I make it run at the right runlevel?
Do I need to make a link in the rd3.d folder? or is there a command to run so it will place itself in the correct runlevels.
Thanks for the explanation.
Use chkconfig --add and add something like:
# chkconfig: 345 20 80
# description: my service
to your script in /etc/init.d
Oh ... and https://serverfault.com/ is definitely a better place for this question.