Bash

This is a simple error I got when I tried to run  apt-get update :

Searching the internet for how to solve this problem, I found out a lot of references regarding proxies – which could not be, I was in my home, I had no proxy and other virtual machines were running and updating without any problem. After some more digging (and after a more accurate reading of the the error), I started suspecting something went corrupt – I don’t know how – with the entire gpg key database of apt.

I tried to test it, removing one at the time all rows on /etc/apt/sources.list – and for every one of them the error was the same.

SOLUTION

I found the answer that worked for me here – AskUbuntu – Can’t update my system due to GPG error . Below is the code:

  • apt-get clean removes all files downloaded by apt . When you install a package, apt download all necessary files and put them in a local archive and then installs it. The directory is /var/cache/apt/archives/ . The cleaning in this case is simply to start anew
  • mv is for the same reason as above, to get a clean environment and to force a new download of all lists from the repositories
  • mkdir recreates the moved directory
  • apt-get update is the command that gave the error that started this post 🙂

MORE IN DEPTH

According to this link:  AskUbuntu – Got NODATA issue: ‘NODATA’ (does the network require authentication?) the error could be caused by the ISP (Internet Service Provider) placing a proxy, maybe a transparent one (Maxcdn – Transparent proxy) in front of your connection. I have to dig deeper on this topic, if this is effectively the reason on this error.

I have configured a few VPNs on my Ubuntu notebook. Some of them are OpenVPN, and in fact they are fairly easy to configure.
However, sometimes I receive this error:

I wasn’t able to exactly identify the situation when this happens – it seems to be related to networking, and it happens more often when I log into my desktop with WI-FI connection, OpenVPN daemon starts, then I plug an ethernet cable.

SHORT ANSWER

A quick solution is simply to log out and log in again. It is simple but I don’t like it very much.

Other than that everything regarding VPNs on Ubuntu Desktop seems to be a bit of a mess. In the long answer you can find some more details regarding OpenVPN.

LONG ANSWER

In Internet you can find a lot of guides on how to set up an OpenVPN on Ubuntu Desktop. One simple and effective is Ubuntu’s Official: Help Ubuntu – OpenVPN. Anyway, most of the times everything is reduced to

to install a service, or

to install an extension to the Network Manager GUI.

However, the GUI option has some limitation – for example, you can only connect to one VPN at the time. If you have more than one VPN (and you can handle all routing problems with overlapping networks that can occur), you have to go with the service. To go with the service, you have to put all your OpenVPN configuration files, with extension .conf, in folder /etc/openvpn . Then (if your configuration files are correct, if your connection is ok, and a billion other ifs) if you restart openvpn service, you should see something like this:

That means that your VPNs are up and running.

However, if you have password authentication, for some reason, even if you have your credentials in a file connected to the configuration file, sometimes the service will hang, simply because the VPN restarts and it is waiting in background for a password. So, you have to restart the service.

But the agent of the first error it’s not this service. They are two completely different things. I think that this agent is something GUI related, for I meet this error only on the network manager GUI, and not with the service – which keeps running. However, it could just be that the service it’s still using WI-FI connection.

Unfortunately I have no real explanation for this and no real solution; just a quick workaround. It is a fairly complicated matter, which would require a lot of debug for a very simple task, and I don’t think it is worth the time.

XARGS error, not replacing on FreeBSD

by admin on

…..at least this was what I thought when I started writing this post. Well, what I found is that in some corner cases, FreeBSD’s xargs command doesn’t behave as expected – as behaves in other OS. Unfortunately, many programs on different OSs are really different programs with similar functionalities and the same name.

Let’s say that  I had this line of bash:

Where:

  • find /path-of-my-directory -mindepth 1 -maxdepth 1 -type d: 
    • find /path-of-my-directory : search within /path-of-my-directory
    • -mindepth 1 -maxdepth 1 : consider just level 1 files and directory
    • -type d: consider only directories
  • | xargs -I {}  bash -c “/scripts/directory/InnerScript –very {} –long {} –series {} –of {} –parameters {} –with {} –something {} –to –replace {}” :
    • | xargs : pipe (forward) results to xargs
    • -I {} : replace {} with piped (forwarded) result
    • bash : shell to use
    • -c “/scripts/directory/InnerScript –very {} –long {} –series {} –of {} –parameters {} –with {} –something {} –to –replace {}” : command line to execute

This command worked well on Ubuntu and other Debian-based servers, but had an odd behaviour on FreeBSD. Sometimes it replaced correctly all {}, some other times it replaced just some {}, some other times it didn’t replace any {} .

What I found is that xargs on FreeBSD has at least one important difference from its equivalent on Ubuntu, at least regarding the command to execute: by default total length of the command must be less than 255 bytes on FreeBSD, at least by default (FreeBSD.org – xargs man, see -I option). Let’s say (even if it is obviously not precise) that it must be less than 255 characters. On Ubuntu, the same default value is 128Kbytes – or less if the maximum system command line length is less than this (Ubuntu Manpage – xargs, see -s option); on my Ubuntu system maximum command line length was about 200Kbyte; on my FreeNAS it was 250Kbyte.

So, on FreeBSD, if you have a long string, you must add -S <number greater than 255> to your commad line:

Sometimes you have to concatenate bash variables. For example, to form a particular filename, you might have a code like this:

As you might have noticed, we have a lot of underscores (in case you don’t know, it’s the symbol _),some part of the variable name,some other not.

If you run (WARNING: do not run this script on production or important files!!!)

you (or at least I) expected to find my moved and renamed file with a full path like this:
/done_files/newName_20150828.done

Well, what you’ll find is this:
/done_files/20150828.done

And if you have run this script multiple times,well,you lost all your files except the last one.

Why this?What can I do?

SHORT ANSWER

The problem is that underscore is a valid character in variable name. To avoid having bash interpreter searching for the wrong variable,you have to put variable name between curly brackets,like this

This way, bash will search for variable name and not for name_ .

LONG ANSWER

Bash interpreter will search for $name_ in variables, won’t find it,so it assumes that it has no value and adds an empty string to your filepath.
That’s, as I said before, because _ is a valid character in variable name! From bash manual, Parameters section:

[blockquote align=left]
A parameter is an entity that stores values. It can be a name, a number, or one of the special characters listed below under Special Parameters. A variable is a parameter denoted by a name.
[/blockquote]

And again, from bash manual, Definitions section:

[blockquote align=left]
name: A word consisting only of alphanumeric characters and underscores, and beginning with an alphabetic character or an underscore. Also referred to as an identifier.
[/blockquote]

So, a variable name can consist only of these characters: a-z A-Z 0-9 _

Underscore is one of them, so in our case it is interpreted by bash as part of the variable name, so it doesn’t find the variable, so it outputs an empty string.

Curly Braces ( that is {} )  in bash are called “Parameter Expansion”.  When you use it in a simple way, like ${name}, it simply reference the variable inside the braces. In this way, you can execute commands like the ones above, concatenating variables and string without problems. Another example of this feature (taken from ) is:

Anyway, curly braces and in general parameter expansion allow to do many more things!! I won’t talk about it here, but I’ll give you this page:

Bash Hackers Wiki – Parameter Expansion

where you can find almost all of parameter expansion functionalities – and related syntax.