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 … ;-) Continue reading »
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. Continue reading »
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 Continue reading »
history command and second, by editing