Skip to content

Instantly share code, notes, and snippets.

@aeros281
Last active September 4, 2024 05:19
Show Gist options
  • Save aeros281/f79fa806e80ca0174394534ba0fa78bf to your computer and use it in GitHub Desktop.
Save aeros281/f79fa806e80ca0174394534ba0fa78bf to your computer and use it in GitHub Desktop.
Dev learning resources

Common knowledge everyone should know

File path

~ (tide)

~ (tide symbol) stand for home directory, this will be different depends on the current user of the current shell. For example on Linux if I logged in as userA, ~ will stand for /home/userA.

So any ~/myfolder is equivalent to /home/userA/myfolder, cd ~ will be equivalent to cd /home/userA.

For macOS the home folder path is /Users/<username>.

Please make sure you are comfortable with using ~ when change directory, remember the full home path name is very cumbersome. Any developer worth their pay need to optimize their workflow.

Relative path

It's simple:

  • . stand for the current directory.
  • .. stand for the parent of the current directory and so on. For example: ../../

/ (slash)

There's a different between these two paths: /folderA and folderA. The initial slash (/) stand for root path. Basically every folder/directory is children or descendants of the root path.

For example: for /home/userA we have 3 levels: root path (/) -> home -> userA. cd /home/userA will follow these paths.

For cd home/userA it's the shorthand for cd ./home/userA which will depends on your current directory, if the current directory is ~ (or /home/userA) then we have 5 levels: root path (/) -> home -> userA -> home -> userA.

This is common mistake that beginner usually have.

Shells

Generally for macOS the default shell will always be ZSH. Common operations:

Update the current shell with latest changes on ~/.zshrc

source ~/.zshrc

Check list of aliases

alias

Environment Variables

https://linux101.hashnode.dev/understanding-environment-variables-in-linux-with-echo

Common Envs

$PATH

When in shell, if you type something like: code and enter, the shell will use $PATH to check for the locations (folders/directories) where a binary named code is presented. For example if $PATH=/home/userA/myfolder:/opt/myfolder (notice the : separator) then we have two paths to check (order specific):

  1. /home/userA/myfolder
  2. /opt/myfolder

If the first path has code binary inside it then the shell will run that binary. If it's not then the shell will check for the second path until all paths are checked.

If both paths has the code binary, the shell the priority the first one.

If all paths are checked but no code binary found then the shell will throw error.

If you install new software which is presented as a binary, for example you installed cloud-sql-proxy, notice the path to that binary.

If the path is something like: /<path1>/<path2>/cloud-sql-proxy which is not presented in $PATH then you should add that path into $PATH. So $PATH=/home/userA/myfolder:/opt/myfolder:/<path1>/<path2>.

In short, everytime you run a command in shell and it shows error related to not existed command, check for $PATH.

Of course if you are comfortable with running the software using the full path then feel free to run using /<path1>/<path2>/cloud-sql-proxy. $PATH is just a simple way to simplify the process of running the binary in shell. But please note that if another software assume that cloud-sql-proxy is included in $PATH but if it's not then that software will break.

Also note that there's a different between using ./cloud-sql-proxy and cloud-sql-proxy in shell:

  1. ./cloud-sql-proxy means you want to run the binary presented on the current folder, so if your current folder is ~/Projects/myproject which is /home/<user>/Projects/myproject then the effect is same as you type /home/<user>/Projects/myproject/cloud-sql-proxy.
  2. cloud-sql-proxy will search $PATH to see if the binary presented on any paths described in it, if it is the shell will execute the first one it found.

Usually this is the reason why when you build any application and test the command to run is usually

./_build/<my_binary>

Because at that point you do not copy the built binary to any paths described in $PATH.

$EDITOR

The system will use this environment when I want to raise any Graphical/Terminal editor. For example: git will use this to open the user editor to ask for commit message everytime we try to commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment