I am currently following the guide to setting up and compiling AOSP in Ubuntu. The problem is I do not have the best knowledge of Linux/Ubuntu.
The part that currently has me confused is setting up the ccache found at this link https://source.android.com/source/initializing.html.
What I don't really understand is the following, which .bashrc file do I need to edit/add the information to? And can I have more than 1 .bashrc file in Ubuntu? Not really sure what this file really does.
Thanks
.bashrc is a file which is called by bash before on each start of a new shell.
This file can be used to setup the environment, export variables, create aliases and functions. There are usually multiple copy of this file, One per system and one per user to allow system wide configuration but also customization by users ( users bashrc will be called at last and can overwrite things).
here you edid or add line to your won user's .bashrc file
type cd $HOME
vi .bashrc
after that change your file and then you have to compile the file using one of the commands.
..bashrc
or
source .bashrc
Related
I have a /.cust_dev_cmds/ directory on my MBP machine that is part of a parent sysadmin-work directory that uses a git repo here. I would like to be able to:
Not have to use a for loop in my .bash_profile to source all the *.sh files.
Add the directory to PATH with and export line in the .bash_profile instead.
# from my .bash_profile
export PATH="/Users/<my-usr-name>/Public/sharable-dev-scripts:$PATH"
This does show up with a echo $PATH but when I try to invoke a function from within the scripts I have created that worked with sourcing directly within the .bash_profile in a loop (like with point #1 above) like this
# create a directory with a builtin command
mkdir test-dir
# use one of my custom ones to create a simple readme.md within that directory:
mkr !!:1
# I am getting >>> mkr: command not found
Use whatever type of link to not have a duplicated directory structure on the machine.
Any good explanations to read up on here without using $10 words would be great.
Define a means to test the link works and works through PATH. It would also be nice that something like declare -F would be available to see that the scripts within the directory are in fact becoming part of callable functions in the shell.
is there a command anyone knows to do this?
Step this up a notch for a shared network directory. I have created a shared directory through apple > System Preferences > Sharing, and turned on the ability to share this directory in the Public folder.
Is there a tutorial that can outline this with something like VirtualBox and an Ubuntu guest that is accessing the commands from the MBP shared directory?
I have realized point #1, so really the question begins with #2 so no one would suggest the first one. I have read a bit on links but the way most of the articles I come across describing them are difficult to wrap my head around- especially when wishing to add this functionality to PATH. I believe the answer may revolve around how links are followed, but it may be better to back up and punt- dig back into linking first- then export my directory appropriately without a link, and eventually get the proper resolution to this situation.
The last thought on links before I try a few hacks on my own is do I need to only add a link to the Public directory and somehow place a flag to look at all the directories within the /Public, or is it better to drill all the way down to the /Public/shared-directory/.cust_dev_cmds? Any direction would be greatly appreciated. My goal is to be able to have a few custom command directories for various tasks, and eventually have them across networks/instances.
When you want all functions that you wrote in files in /.cust_dev_cmds/, the normal way would be sourcing all the files.
When you want to avoid a loop, you can use
utildir="$HOME/.cust_dev_cmds/" # I think the path is relative to your home).
source <(cat ${utildir}/*)
When you want the functions found with the PATH, you should make a file for each function.
Before:
# cat talk
ask() { echo "How are you?"; }
answer() { echo "Fine, thank you"; }
After:
# cat ask
echo "How are you?"
# cat answer
echo "Fine, thank you"
When you want all users to use the same set of functions, consider a master script that sources all scripts (the masterfile can use user=dependent settings like HOME or VERSION):
# cat /Public/shared-directory/setup_functions
utildir="$HOME/.cust_dev_cmds/" # I think the path is relative to your home).
source <(cat ${utildir}/*)
source some_other_file
Now each user only needs to source one file.
I am learning my way through shell scripts and just created one with vim.
Every file I create with .sh extension seems to be defaulting to read-only mode for every group in the ls -l command. I have tried creating files with several editors and in several locations and always get the same result.
So my question is, I know i can chmod the files so i can execute them, but is there something i can do to create them executable already and not change every single one of them?
As with any UNIX-like system, file creation is affected by the umask, which masks out file access bits when files are created.
You can change the default umask by editing the shell start-up configuration files, however I wouldn't recommend doing that.
If you want to change it so that all files you create have the executable bit set by default, then what about files that are not executable? I have always worked on shell scripts with the edit, chmod, run cycle and I don't feel it's a big problem.
I have been looking throughout the system but I cannot find it. When I do echo $PATH I get the stuff I added, plus the default path. I do not have a .profile, and I do have a .bashrc, but the default path is not in there. I am looking for it just to know where it is located because all the tutorials explain that its in .profile... but what if you don't have one? Where is it located then? Anybody have any ideas?
If you do sudo man path_helper, it talks a bit about how it puts the path together. You might look in /etc/paths and /etc/paths.d. I did, and found what I was looking for.
Many system-wide settings including PATH are set in /etc/profile which is read in by bash at startup. On Mac OS X this file usually uses path_helper to set PATH. This utility in turn reads the information from other system configuration files under /etc (see path_helper manpage).
Note that even if you disable the reading of the initialization files by bash (e.g. with command-line options like --noprofile) it will still inherit the environment of the parent process.
If you start at /etc/profile, it should look something like this:
if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
fi
It's testing to see if the file exists and if so, executes it. If you execute it by hand, you'll get something like this:
PATH="/usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin"; export PATH;
I believe that's what you're looking for. So it comes from /etc/profile, which in turn calls an executable that sets the path.
As mentioned in the accepted answer, the $PATH is built by first looking into the content of the file /etc/paths, and then looking into every file in the folder /etc/paths.d. So, the $PATH in the pre-installed bash system installation contains every entry in these files, as well as in other shell types.
However, because in the latest Mac OS versions the default shell is zsh, I followed a couple of tutorials in which the writer avoided to change the $PATH for the bash shell, and simply added new entries to the $PATH by editing ~/.zshrc the following way:
export PATH=/path/available/only/for/zsh/shells:$PATH
The above command adds /path/available/only/for/zsh/shells to the $PATH, and the added path will only be available in zsh shells.
I hope this helps someone who, like me, had too many entries in the $PATH in zsh shells, and couldn't figure out where they were coming from!
The .profile file on Mac is located in your user folder: ~/Users/youruser/
However, the .profile file is hidden. You can press Command+shift+. (command, shift, dot) while on Finder to see them.
There's one important fact I only realized today while debugging a problem: the profile settings (.bash_profile etc.) are only read by login shells. They are not read by the processes that are used to launch your applications.
You launch your applications in diverse ways: click the icon in /Applications, or type the name in Spotlight search, or click an icon in the Dock ... In all those cases, the application itself (i.e the binary or shell script inside the application) is launched by launchd without any parent shell. Meaning that your profile is not run and that your custom settings (PATH, environment variables ...) will be ignored.
That can cause all sorts of trouble, for example if you setup you environment to use a specific version of Java: your application will not see that and use the "default" java, which will be the one with the highest version number.
In my case, the problem is that my application was crashing when run via the application launcher, but runs fine when run from a terminal window ... The reason was that I had a custom path that included some libraries required by the application, but that was not available when the application was run by the launcher.
The solution I used was to symlink the libraries needed into /usr/local/lib
Is it dangerous, insecure or not-so-smart for any other reason to put a custom shell script to /usr/bin and add /usr/bin to $PATH in order to make a custom script executable from everywhere without ./ and the file extension?
Bonus question: can I assign custom icons to custom executable scripts?
Traditionally, /usr/bin is one of the places where operating system binaries are stored. For custom scripts, you'd use /usr/local/bin. This you have to create yourself if it does not exist and add to $PATH, as you mentioned.
Icons are a GUI thing, shell scripts are a CLI thing. They live in separate universes. Nothing prevents you from creating a bridge though. For instance, you can make a shell script and call it foo.command. Opening this from the GUI starts Terminal and runs the script. Since you see the file in the Finder, you can assign it a new icon through the Info pane.
Also, you may want to take a look at the free Platypus application. It allows you to create a full-blown application bundle around a script. The bundle will contain the script, so you won't have to put it in some obscure directory and modify $PATH. If you also need CLI access, this option is less desirable.
I wrote a command line tool for setting the custom icon of a file. You can grab it here.
I'm on a Mac and I'm trying to make a Vim plugin for compiling/running actionscript files.
First, I need to run mxmlc on the command line, but to do that I have to keep on typing the path to it. Where do I place it so that I don't have to retype the path?
You need to modify your "$PATH" environment variable, so that the tool is in that directory. However, if you want to make this very easy... you can download my macosx-environment-setup.tar.bz2 program. If you execute the "install.sh" script using "sudo ./install.sh", it will setup your environment in such a way that if you use "/Library/Flex4SDK" as the location for the Flex4SDK, it will automatically find it, define FLEX_HOME to point to that location, and it will also ensure that the binaries from the Flex4SDK are in your PATH.
Side Note: This is up on the web, because I use it in my Development Environment Setup How-To Guides. If you aren't too keen about running "sudo ./install.sh", you need to choose a location (I am going to assume "/Library/Flex4SDK", so that the tools are located in "/Library/Flex4SDK/bin"), and then you would simply need to edit your "~/.profile" file (using "nano ~/.profile"), adding the following to the very end:
export FLEX_HOME=/Library/Flex4SDK
export PATH="$PATH":"$FLEX_HOME/bin"
Note that these changes occur in your shell... they will not affect programs that are launched by double-clicking them in Finder. In order to affect those programs, you will need to place the environment variables in a file named ~/.MacOSX/environment.plist. See Automatically build ~/.MacOSX/environment.plist for a script that will automatically generate such a file using the current environment variables defined in your shell.
There are a few ways to answer this:
In one of your directories searched
by PATH (see the list with echo
$PATH)
Add a new directory to PATH
(e.g. in your ~/.bashrc
export PATH=$PATH:/path/to/bindir)
Add an
alias to your program (e.g. in your
~/.bashrc alias
mxmic=/path/to/mxmic)
(I'm assuming you're using bash shell, which is usually the case you can check with echo $SHELL)