DEV Community

Linux's commands and tricks I'm using in my daily job as a developer

Mateusz Jarzyna on November 11, 2019

This is not a post from the series of those describing the cd command. It's just a list of commands and tricks I'm using (almost) every day. ...

Read full post

simonced • Nov 12 '19 • Edited

Those are great tips.

In the terminal, one trick I like is going back to previous folder with

cd -

(that is a minus sign)

Say, you are in /var/logs and you cd /data/dev/myproject, then you can go back to logs with cd -.

Useful in some situations only, but quite handy nonetheless.

Charles Banas • Nov 12 '19

If you're editing config files with vim and need to use that sudo tee hack, stop.

You should be using sudoedit. It safely copies the config to /tmp and runs $EDITOR as your regular user with your user config, and only overwrites the file you're editing if you actually save. This is far more desirable than running your editor as root.

Maxime Moreau • Nov 12 '19

Very good point, I think that we should never use sudo vim.

Patryk • Nov 16 '19 • Edited

alt + . is a great one too, in bash.

$ mkdir -p /tmp/some/nested/directory
$ cd <alt+.> # types the LAST argument - /tmp/some/nested/directory

Re: netstat, it still works, of course, and you can continue using it, but it is deprecated in favour of ss.

Re: sshing into a DB server as root, no offence, but I don't believe your company actually has a security policy :D (hopefully it was just an example).

Mateusz Jarzyna • Nov 16 '19 • Edited

Re: sshing into a DB server as root, no offence, but I don't believe your company actually has a security policy :D (hopefully it was just an example).

Yup, it was a 'funny' example

Guillermo Tobar • Nov 19 '19

For years I looked for this, and finally found it. Thank you very much for your contribution Patryk.

PatricNox • Nov 11 '19

Working with drush, the last one is very neat!

I have a concern regarding "Yes". I find it a bad idea to use this since what if you encounter a new tool? Maybe you install something and Yes makes it install, or maybe skip, dependencies that's crucial to have/not have in the project

(Vague example scenario, but you get the point!)

Ben Sinclair • Nov 11 '19

A lot of commands take a -y flag too.

If you're particularly concerned about it doing something you don't want, you can use an expect script instead. It's kind of like selenium for the command line.

PatricNox • Nov 11 '19

Yep! I tend to use the y flag.

Mateusz Jarzyna • Nov 11 '19

Thanks, PatricNox! I've added little warning in the post

Mateusz Jarzyna • Nov 11 '19

Yup, you are right. yes program may do unexpected thing, but sometimes you do know the script very well and you know all the questions.
Maybe I should change the example and add some warning

Thomas H Jones II • Nov 13 '19

Last command
To execute last command over again you can of course press ↑ (arrow up) key. But you can also type !!. So executing last command as a root is very easy

While !! is great, the overall ! method becomes really powerful if you understand that you're neither limited to re-executing just the last command or re-executing the command relatively unmodified.

Previously executed ssh host1.my.domain and now need to connect to host2.my.domain? Execute either of ^host1^host2^ or !!:s/host1/host2
Related to the latter, if you execute history and see that you previously connected to host1 with the 23rd command in your history-buffer, you could do !23:s/host1/host2
Have a command in your history that had a repeating string that you'd like to substitute all values for? !43:gs/orig_string/new_string

Agree for everything

I would be suuuuuuuper leery about developing habits around the yes command. Great sadness can ensue from habituating to its use ...especially if you have privileged access to a system. For commands that implement a built-in auto-yes feature (e.g. your yum does via the -y flag). Even there, I'd tend to avoid auto-yes except in the very specific context of scripted routines where you've validated the the auto-acknowleged behavior always acts the way you expect and need it to.

It's also worth noting that not every command you use will understand accepting a yes from piped <STDIN>

Run a long-lasting process in the background and close the terminal

There are a non-trivial number of commands that don't react well to being backgrounded. You might think, "lemme background this thing and let it go about its business" only to come back minutes/hours/days later to find that it's done nothing. Basically, whenever you background a command, it's always a good idea to run the jobs command immediately afterwards to verify that it's in a running state. You may, instead, find that your backgrounded command is in a stopped state.

Even better than using shells' built-in job-control for long-running tasks may be to use a terminal-multiplexer like screen or tmux. They're also great if you're connecting to a system over crappy links (remote in, fire up screen, kick off your tasks ...even if your connection dies, stuff keeps running and you can re-connect and re-attach to your session to finish things up).

João Paulo dos Santos Portela • Nov 19 '19

Yeah! I was also going to suggest tmux instead of nohup.

the-harry • Nov 19 '19

Great tips! I think it worth to mention the !$ operator in addition to !!.
Where !$ is the argument of last command.
So if you:

mkdir foo

You can enter the folder typing:

cd !$

mgfrobzz • Nov 12 '19 • Edited

If you have to telecommute, and your company's vpn connection is sh*tty, and they don't allow you to ssh in, reverse ssh tunneling is your friend:
thegeekstuff.com/2013/11/reverse-s...

Jack Kingsman • Nov 12 '19

Also a good way to get your security team grumpy with you ;) Outbound SSH from prod sets off about a dozen alarm bells for us. Talking to your manager or DevOps team member is another option for addressing rough inbound access :)

Patrick Hanford • Nov 13 '19

Awesome list.

I vote to add ctrl + r for searching your previous commands to this list!

Testing Gunicorn or Prometheus or something with a long pipeline? Run it once then ctrl + r and type some keywords to find it again without having to type it all out or mash the up arrow.

Vinay Hegde • Nov 11 '19

If you've a common SSH login with sudo (shouldn't be the case mostly), do be careful with !! as you could end up running a potentially dangerous command in a hurry.

You could use sudo lsof -i :80 to identify which app is taking up a port instead of netstat & ps

Also zless to view gzipped logs without extraction & wget -c URL to retry downloads in case of issues.

iamnielsjanssen • Nov 12 '19 • Edited

For me 'screen' is unmissable when working in terminal applications. It is like having multiple windows! ctrl-a then 'c' creates new screen, ctrl-a 'space' switches through screens.

Keith Sloan • Nov 15 '19

Agreed. I tend to map my F-keys to swich between next, prev and list screens.
bindkey -k k3 prev
bindkey -k k4 next
bindkey -k k5 windowlist

Jon Austin • Nov 20 '19

generally use tmux nowadays

Araslanov Eugene • Nov 19 '19

This also works in git

  git checkout -

Luan Fonseca • Nov 19 '19

A lot of git commands works with the -

Like:

(my-branch*) $ git checkout develop
Switched to branch 'develop'
Your branch is up-to-date with 'origin/develop'.

(develop*) $ git checkout my-branch
Switched to branch 'my-branch'

(my-branch*) $ git merge -
Already up-to-date.

Gergely Polonkai • Nov 19 '19 • Edited

ll is actually a convenient alias set on most systems. Aliases are really powerful in and of themselves and worth a separate article (in fact, there’s a lot out there…)

SerjP • Nov 13 '19

A "nice" command with 'yes' is:

yes >/dev/sdaX &

where X is 1, 2, etc
Wipes your hdd with "yes".
:)))

Vladimir Nikolic • Nov 14 '19

Your title is misleading kind of.
Says commands you use in daily job, implies you are using them every day? Or that you use those command in your daily job as developer. If second whats your night job?
I dont see any command i would run daily.
Sorry to say but i dont see any of these commands so useful for daily work.
Hard to believe you would be executing ssh -L{port on your PC}:localhost:{database's port} root@{server IP} daily (or almost) instead of creating an alias, same as for the other longer command you mention.
Or this:
0 22 * * 1-5 /opt/scripts/send-report.sh 2>/var/log/scripts/report-error.log
Really? Almost daily?
Cant take this seriously :)