Blog - page 2 newer posts
In this lesson I wanna show you a command, that gives you
with just two keystrokes a load of useful information about a linux system.
What you can expect
In this lessen I will talk about
The one command I always type in at first after logging in into a system. The current time and the timezone your system is configured with How to find out, if your system is currently overloaded or not If there are other users active on the system and what they are doing
(Yes - linux is a multi-user environment. And therefore it’s often very useful to see, what other users are doing on the system at the time you are working there.)
read more »
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 …
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 … ;-)
read more »
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.
read more »
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
read more » newer posts