What the heck are they using xargs for?

You know how to connect two tools via stdin and stdout? Great!

• But how about the commands that don’t read from it’s input-datastream?
• How to interconnect commands together, that naturally won’t fit?

This is, where xargs comes into play.

And because I know your time is precious - I’ve created this really short video-training … only 7:32 min :-)

In this video you will also discover …

• the one big philosophy you can expect from most linux-tools

• which commands can be interconnected directly

• and the only two parameters you need for controlling the behavior of xargs most of the time.

So sit back, watch and enjoy …

If your shell always get’s you wrong - quote the right way

Here is another question that often comes up by my students and clients:

” … how can I solve the problem with these special-characters? The shell always gets me wrong …”

The fast and simple answer to this is: You have to quote!

… and you have to to it the right way.

But let’s start from the beginning:

As you know, there are characters at the command line, that simply has special meanings for the shell.

You use them for instance, for referencing the content of a variable (“$”)

robert@demo:~$ echo Hello $NAME

… or for redirecting a datatream to a file (“>”):

robert@demo:~$ ls -l /etc > $TEMPFILE

But everytime you wanna use these special characters without their special meaning for the shell, you have to take special care about it.

(huh - three times “special” in one sentence. this must be really special ;-) )

So instead of writing

robert@demo:~$ echo Buy this book for $9 now
Buy this book for now

you have to write something like

robert@demo:~$ echo 'Buy this book for $9 now'
Buy this book for $9 now

In this way, the shell won’t try to interprete $9 as a variable. Instead it would take the “$”-sign just like what it is: a $-sign.

This mechanism is called “quoting” and technically explained for instance in depth in the Bash-Documentation.

Let me show you, how the quoting works. And your shell never gets you wrong again … ;-)

SSH port-forwarding from within the Google Cloud Shell

Google provides a very useful tool especially for those I’m calling “cloud workers”: the Cloud Shell. This gives you access to a linux-shell for just whatever you do usually in a linux shell - directly from your browser.

From time to time I use the cloud shell as a starting-point to connect via ssh to other systems. Recently I noticed that tcp-port-forwarding via the outgoing ssh-connections doesn’t work out of the box: When trying to establish a port-forwarding (ssh user@targethost -L 8080:127.0.0.1:8080) the following error occurs:

bind: Cannot assign requested address

… and the port-forwarding doesn’t work.

The reason for this is simple - as always as you know it: The ssh-client tries to bind to the local ipv6-port. This is not supported in the cloud shell and therefore fails.

How to delete command lines from the bash history

And suddenly it happened again: I’ve typed sensitive information (at this time it was a password) into the command line.

And the shell kindly saved the typed commandline into its history. This way it wants to help me if I need the same command line later again. Great!

But what happens, if the system I’m working on isn’t under my full control? Imagine I’ve worked on a customer system …

Or what if someone later looks over my shoulder while I’m searching through my history?

The sensitive line needs to be removed!

• What’s the best way for doing this?
• How do we protect ourselves from this happening again later?

Generally speaking: You have two options to remove command lines from the bash history: first, by using the history command and second, by editing ~/.bash_history directly.