What I am trying to do is have my current ASCII ART appear on start up as well as have ls run so I can see my directories. I assume this is going to be a script that I will have to do so if anyone can point me in the right direction to get started that would be awesome. Thank you!
You'll most likely want to add whatever commands display your ASCII art and ls to the end of the ~/.bash_profile file. See here.
In other words, open the /Users/$USER/.bash_profile file in a text editor (or create it if it doesn't exist) and put ls at the end of the file on its own line.
This startup shell file is also called .profile or .bashrc on other linux/unix systems. More information on this behavior is available here. The scripting language for the file is bash.
Related
I am loosing a lot of time searching in internet for the following simple setting.
I installed git (and git bash) in Windows. What I want is just to open Git Bash and be in the directory I want. I don't want to change my home directory, just be in a given directory when I open the program.
More detailed, when I open Mingw / Git bash in Windows, I would like to be in the following folder:
/c/blabla/my_git_repositories
(this corresponds to the windows-style path: C:\blabla\my_git_repositories).
At the moment, I must write the following command every time I open GitBash:
cd /c/blabla/my_git_repositories
is this possible? Which file should i modify?
Actually the program is installed here:
C:\Program Files\Git\mingw64
Thanks
If you want it happening every time you start an interactive shell, add
cd /c/blabla/my_git_repositories
to your shell startup. If your install includes the manpages say man bash and find the INVOCATION section, in a decent pager just /^INV will do it. Or Google knows to interpret a search for man bash as a search for the bash manpage.
Windows doesn't ordinarily support shell logins at all so a lot of the shell's startup-circumstance detection is overkill on Windows. Executing it is extremely fast, but describing exactly how it decides takes a page or two.
The short form is, if the startup was told it's a login shell it reads the login startup files, including (your) ~/.bash_profile, which generally should check for an interactive login and if so source the normal interactive shell startup ~/.bashrc, so ~/.bash_profile should end with something like
[[ $- = *i* && -f ~/.bashrc ]] && . ~/.bashrc
and put whatever you want in ~/.bashrc. That cd, set up your prompt colors, define your favorite shell aliases, add your personal scripts directory to PATH, whatever.
Partial solution when opening the program by clicking on a link.
Right click on the link → properties → Start in: set the value to "C:\blabla\my_git_repositories".
This will work only when you open the application from that link, but could be fine (depending by your needs).
While using git bash terminal, I can't print a pdf file. In fact I can't print anything. I am using correct file name and I've tried typing:
lp file.pdf
but I get bash:
lp: command not found
I get same promt when trying to print anything using lp command.
How do you print from git bash terminal?
Git bash is an emulated bash. The standard programs available on most Linux distributions are not available there.
Windows programs are available. You can run them, but you'll have to make sure all the details are set up, and sometimes they don't like the environment.
For example, both notepad and wordpad (write) should be able to use the /p and/or /pt options, but you may have trouble getting it to find the file.
write tst
will open the file in wordpad, and
write /p tst
is supposed to print it, assumedly to the default printer, though my config seems admin-locked to something stupid.
Maybe that will help. Good luck.
I set up some aliases in my .bash_profile on my Max OS X.
It works but when I'm opening a new tab I always have to load my .bash_profile file with this command:
source ~/.bash_profile
How can I make it work for every terminal I'm opening, even if I'm restarting my Mac or Linux computer?
If you use zsh , you can add source ~/.bash_profile
at the end of .zshrc file at the following path: /Users/YOUR USER NAME/.zshrc , then restart your Terminal/iTerm2 app.
Note that this file is hidden. You can press CMD + SHIFT + . in Finder to
see it, Or just open it in default text editor with the following command from terminal:
open ~/.zshrc
Update
You don't need to do this by hand, run the following command:
echo "source ~/.bash_profile" >> ~/.zshrc
* Dont forget to restart your terminal.
The files executed at the start may be several, usually ~/.bashrc for interactive, non-login shells. The kind I assume you are using.
If so, create an ~/.bashrc file and source ~/.bash_profile in it:
if [ -f ~/.bash_profile ]; then
. ~/.bash_profile
fi
This web site has a lot of information about this.
Study this image, as it is a condensed guide
If you do need to find out exactly which file is being executed, take a look at this web page. It has a lot of specific tests to find out what file is setting what.
Specific for Mac-OS (which is an exception and loads ~/.bash_profile) do as is recomended in the site linked in this answer AFTER you confirm that your bash is doing as explained there.
I know this is a pretty old post, but this problem comes and goes quite oftenly and a lot of laborous solutions are offered. The fact is: being aware of a simple info would solve this pretty fast and easy:
LINUX/Unix OS will load the profile files on startup following the rules below (some distros may have other files names, mainly for user local profiles, but the main rule follows this):
Login Shell
First and foremost: /etc/profile is loaded (global settings);
Next: ˜/.bash_profile (local user settings- other files may be found, like ˜/.profile, depending on the distro. Check documentation).
So, if you are in a Login Shell environment, put all your crazy stuff inside ˜/.bash_profile (or the file provided by your distro) and everything will be fine.
Non-login Shell
First and foremost: /etc/bashrc (some distros will load bash.bashrc);
The next file to be seeked and loaded is ˜/.bashrc
And that's why so many people (just like me) got frustrated having to source their ˜/.bash_profile every single time a Terminal was loaded. We were simply inserting info in the "wrong" file- regarding the kind of shell loaded (see above: login, non-login).
More details on variants of the files mentioned above and some info on login vs non-login shell can be found here.
Hope it helps \o/
I have written a bash script in a text editor, what extension do I save my script as so it can run as a bash script? I've created a script that should in theory start an ssh server. I am wondering how to make the script execute once I click on it. I am running OS X 10.9.5.
Disagreeing with the other answers, there's a common convention to use a .sh extension for shell scripts -- but it's not a useful convention. It's better not to use an extension at all. The advantage of being able tell that foo.sh is a shell script because of its name is minimal, and you pay for it with a loss of flexibility.
To make a bash script executable, it needs to have a shebang line at the top:
#!/bin/bash
and use the chmod +x command so that the system recognizes it as an executable file. It then needs to be installed in one of the directories listed in your $PATH. If the script is called foo, you can then execute it from a shell prompt by typing foo. Or if it's in the current directory (common for temporary scripts), you can type ./foo.
Neither the shell nor the operating system pays any attention to the extension part of the file name. It's just part of the name. And by not giving it a special extension, you ensure that anyone (either a user or another script) that uses it doesn't have to care how it was implemented, whether it's a shell script (sh, bash, csh, or whatever), a Perl, Python, or Awk script, or a binary executable. The system is specifically designed so that either an interpreted script or a binary executable can be invoked without knowing or caring how it's implemented.
UNIX-like systems started out with a purely textual command-line interface. GUIs like KDE and Gnome were added later. In a GUI desktop system, you can typically run a program (again, whether it's a script or a binary executable) by, for example, double-clicking on an icon that refers to it. Typically this discards any output the program might print and doesn't let you pass command-line arguments; it's much less flexible than running it from a shell prompt. But for some programs (mostly GUI clients) it can be more convenient.
Shell scripting is best learned from the command line, not from a GUI.
(Some tools do pay attention to file extensions. For example, compilers typically use the extension to determine the language the code is written in: .c for C, .cpp for c++, etc. This convention doesn't apply to executable files.)
Keep in mind that UNIX (and UNIX-like systems) are not Windows. MS Windows generally uses a file's extension to determine how to open/execute it. Binary executables need to have a .exe extension. If you have a UNIX-like shell installed under Windows, you can configure Windows to recognize a .sh extension as a shell script, and use the shell to open it; Windows doesn't have the #! convention.
You don't need any extension (or you could choose an arbitrary one, but .sh is a useful convention).
You should start your script with #!/bin/bash (that first line is understood by execve(2) syscall), and you should make your file executable by chmod u+x. so if your script is in some file $HOME/somedir/somescriptname.sh you need to type once
chmod u+x $HOME/somedir/somescriptname.sh
in a terminal. See chmod(1) for the command and chmod(2) for the syscall.
Unless you are typing the whole file path, you should put that file in some directory mentioned in your PATH (see environ(7) & execvp(3)), which you might set permanently in your ~/.bashrc if your login shell is bash)
BTW, you could write your script in some other language, e.g. in Python by starting it with #!/usr/bin/python, or in Ocaml by starting it with #!/usr/bin/ocaml...
Executing your script by double-clicking (on what? you did not say!) is a desktop environment issue and could be desktop specific (might be different with
Kde, Mate, Gnome, .... or IceWM or RatPoison). Perhaps reading EWMH spec might help you getting a better picture.
Perhaps making your script executable with chmod might make it clickable on your desktop (apparently, Quartz on MacOSX). But then you probably should make it give some visual feedback.
And several computers don't have any desktop, including your own when you access it remotely with ssh.
I don't believe it is a good idea to run your shell script by clicking. You probably want to be able to give arguments to your shell script (and how would you do that by clicking?), and you should care about its output. If you are able to write a shell script, you are able to use an interactive shell in a terminal. That it the best and most natural way to use a script. Good interactive shells (e.g. zsh or fish or perhaps a recent bash) have delicious and configurable autocompletion facilities and you won't have to type a lot (learn to use the tab key of your keyboard). Also, scripts and programs are often parts of composite commands (pipelines, etc...).
PS. I'm using Unix since 1986, and Linux since 1993. I never started my own programs or scripts by clicking. Why should I?
just .sh.
Run the script like this:
./script.sh
EDIT: Like anubhava said, the extension doesn't really matter. But for organisational reasons, it is still recommended to use extensions.
I know this is quite old now but I feel like this adds to what the question was asking for.
If your on a mac and you want to be able to run a script by double clicking it you need to use the .command extension. Also same as before make file executable with chmod -x.
As was noted before, this isn't really that useful tbh.
TL;DR -- If the user (not necessarily the developer) of the script is using a GUI interface, it depends on what file browser they are using. MacOS's Finder will require the .sh extension in order to execute the script. Gnome Nautilus, however, recognizes properly shebanged scripts with or without the .sh extension.
I know it's already been said multiple times the reasons for and against using an extension on bash scripts, but not as much why or why not to use extensions, but I have what I consider to be a good rule of thumb.
If you're the type who hops in and out of bash and using the terminal in general or are developing a tool for someone else who does not use the terminal, put a .sh extension on your bash scripts. That way, users of that script have the option of double-clicking on that file in a GUI file browser to run the script.
If you're the type who primarily does all or most of your work in the terminal, don't bother putting any extension on your bash scripts. They would serve no purpose in the terminal, assuming that you've already set up your ~/.bashrc file to visually differentiate scripts from directories.
Edit:
In the Gnome Nautilus file browser with 4 test files (each with permissions given for the file to be executed) with stupidly simple bash command to open a terminal window (gnome-terminal):
A file with NO extension with #!/bin/bash on the first line.
It worked by double-clicking on the file.
A file with a .sh extension with #!/bin/bash on the first line.
It worked by double-clicking on the file.
A file with NO extension with NO #!/bin/bash on the first line.
It worked by double-clicking on the file...technically, but the GUI gave no indication that it was a shell script. It said it was just a plain text file.
A file with a .sh extension with NO #!/bin/bash on the first line.
It worked by double-clicking on the file.
However, as Keith Thompson, in the comments of this answer, wisely pointed out, relying on the using the .sh extension instead of the bash shebang on the first line of the file (#!/bin/bash) it could cause problems.
Another however, I recall when I was previously using MacOS, that even properly shebanged (is that a word?) bash scripts without a .sh extension could not be run from the GUI on MacOS. I would love for someone to correct me on that in the comments though. If this is true, it would prove that there is a least one file browser out there where the .sh extension matters.
Often I find my self navigating the filesystem from a Conque shell in Vim and want to open a specific file inside my existing MacVim session. Is this possible ? - I was hoping for something like:
shell> open some/file.txt
and then have file.txt pop up inside my existing Vim window (preferably in a new tab).
Note: I am using #wycats vim dot files (not sure this matters).
Type from ConqueShell
mvim --remote-tab-silent filename
This will open the file in a new tab in MacVim
You could also write a Bash alias to shorten the command (assuming you are using bash).
Put in your ~/.profile
alias vim='mvim --remote-tab-silent'
this would enable you to type
vim filename
from ConqueShell or bash, and have it open in a new MacVim tab, rather than terminal vim. It of course does disable your ability to run standard vim (although you could still use the vi command), so maybe you would want to name the alias differently.
Just to add, this will work only if you placed the mvim executable on your path E.G. /usr/bin/mvim. It comes with the MacVim.app
Often I find my self navigating the filesystem from a Conque shell
The beauty of running a shell from inside vim is you have all of vim and the shell at your disposal.
gf is your friend. Once you get the file you want displayed on the screen in some way, you can enter normal mode, move the cursor to the file you want to edit, then use the gf command to navigate to the file. There are many ways to use this. Any program or command that outputs file names is great for this (ll, git status, etc). You could also type the filename into the shell, just to make it visible on the screen without actually running any terminal commands (tab completion is handy here).
It is possible, you can start vim as server and then add as many files as you want, but I'm not very familiar with this, so I can't give you just a direction.