Adventures & experiences in contemporary technology
On Friday, I was working on a system where a session is instantiated from a stored virtual machine that produces a fresh session every time so all previous changes get lost. What I have is a batch script that I run to reinstate what I need and I encountered another task that I wanted it to do.
Part of my work involves the creation of plain text files with the extension lst and this is getting associated with SAS instead of Notepad. While you can reassign such associations using the GUI, it would be nice to do it via the command line too so the assoc and ftype commands caught my interest. The first of these associates a file with a given extension with a desired file type while the second shows the available file types together with the associated applications that open them. The assoc command also show all the associations that are in place when it is executed with no parameters and the ftype command does the same for file types.
Once you have picked out a file type with the ftype command, then the assoc can be used like the following:
assoc .lst=txtfile
The above associates an extension with a file type. In the this, .lst files are going to get opened by Notepad because of the txtfile association. Though it did not do what I wanted on Friday due to system lockdown, it is good to know that this is possible and that even the Windows command line supports goodies like these.
Here are some Linux commands that I encountered in a feature article in the current issue of Linux User & Developer that I had not met before:
cd --
This returns you to the previous directory where you were before with having to go back through the folder hierarchy to get there and is handy if you are jumping around a file system and any other means is far from speedy.
lsb_release -a
It can be useful to uncover what version of a distro you have from the command line and the above works for distros as diverse as Linux Mint, Debian, Fedora (it automatically installs in Fedora 22 if it is not installed already, a more advanced approach than showing you the command like in Linux Mint or Ubuntu), openSUSE and Manjaro. These days, the version may not change too often but it still is good to uncover what you have.
yum install fedora-upgrade
This one can be run either with sudo or in a root session started with su and it is specific to Fedora. The command performs an upgrade of the Fedora distro itself and I wonder if the functionality has been ported to the dnf command that has taken over from yum. My experiences with that in Fedora 22 so far suggest that it should be the case though I need to check that further with the VirtualBox VM that I have created.
Once you end up with Windows overwriting your master boot record (MBR), you have lost the ability to use GRUB. Therefore, it would be handy to get it back if you want to start up Linux again. Though the loss of GRUB from the MBR was a deliberate act of mine, I knew that I’d have to restore GRUB to get Linux working again.So, I have been addressing the situation with a Live DVD for the likes of Ubuntu or Linux Mint. Once one of those had loaded its copy of the distribution, issuing the following command in a terminal session gets things back again:
sudo grub-install --root-directory=/media/0d104aff-ec8c-44c8-b811-92b993823444 /dev/sda
When there were error messages, I tried this one to see if I could get more information:
sudo grub-install --root-directory=/media/0d104aff-ec8c-44c8-b811-92b993823444 /dev/sda --recheck
Also, it is possible to mount a partition on the boot drive and use that in the command to restore GRUB. Here is the required combination:
sudo mount /dev/sda1 /mnt
sudo grub-install --root-directory=/mnt /dev/sda
Either of these will get GRUB working without a hitch and they are far more snappy than downloading Boot-Repair and using that; I was doing that for a while until a feature on triple booting appeared in an issue of Linux User & Developer that reminded me of the more readily available option. Once, there was a need to manually add an entry for Windows 7 to the GRUB menu too and, with that instated, I was able to dual-boot Ubuntu and Windows using GRUB to select which one was to start for me. Since then, I have been able to dual boot Linux Mint and Windows 8.1 with GRUB finding the latter all by itself so your experiences too may show this variation so it’s worth bearing in mind.
Last week, I kept getting a multitude of messages from Ubuntu’s crash reporting tool, Apport. So many would appear at once on reaching the desktop session during system start-up that I actually downloaded an installation ISO disk image with the intention of performing a fresh installation to rid myself of the problem. In the end, it never came to that because another remedy produced the result that I needed.
Emptying /etc/crash was a start but it did not do what I needed and I disabled Apport altogether. This meant editing its configuration file, which is named apport and is found in /etc/default/. The following command should open it up in Gedit on supplying your password:
gksudo gedit /etc/default/apport
With the file opened, look for the line with enabled=1 and change this to enabled=0. Once that is done, restart Apport as follows:
sudo restart apport
This will need your account password to be supplied before it will act and any messages should appear thereafter. Of course, I would not have done this if there was a real system problem but my Ubuntu GNOME installation was and is working smoothly so it is the remedy that I needed. The idea behind the tool is that Ubuntu developers get information on any application crashes but I find that it directs me to the Ubuntu Launchpad bug reporting website and that requires a user name and password for the information to be processed. For some reason, that is enough to stall me and I wonder if there could be a way of getting developers what they need without adding that extra manual step. Then, more information gets supplied and we get a more stable operating system in return.
The progress of Windows 10 is something that I have been watching. Early signs have been promising and the most recent live event certainly contained its share of excitement. The subsequent build that was released was another step in the journey though the new Start Menu appears more of a work in progress than it did in previous builds. Keeping up with these advances sometimes steps ahead of VirtualBox support for them and I discovered that again in the last few days. VMware Player seems unaffected so I thought that I’d try a migration of the VirtualBox VM with Windows 10 onto there. In the past, I did something similar with a 32-bit instance of Windows 7 that subsequently got upgraded all the the way up to 8.1 but that may not have been as slick as the latest effort so I thought that I would share it here.
The first step was to export the virtual machine as an OVF appliance and I used File > Export Appliance… only to make a foolish choice regarding the version of OVF. The one that I picked was 2.0 and I subsequently discovered that 1.0 was the better option. The equivalent command line would look like the following (there are two dashes before the ovf10 option below):
VboxManage export [name of VM] -o [name of file].ova --ovf10
VMware have a tool for extracting virtual machines from OVF files that will generate a set of files that will work with Player and other similar products of theirs. It goes under the unsurprising name of OVF Tool and it usefully works from a command line session. When I first tried it with an OVF 2.0 files, I got the following error and it stopped doing anything as a result:
Line 2: Incorrect namespace http://schemas.dmtf.org/ovf/envelope/2 found.
The only solution was to create a version 1.0 file and use a command like the following (it’s a single line though it wraps over two here and there are two dashes before the lax switch):
ovftool --lax [name of file].ova [directory location of VM files]/[name of file].vmx
The --lax option is needed to ensure successful execution even with an OVF 1.0 file as the input. Once I had done this on my Ubuntu GNOME system, the virtual machine could be opened up on VMware Player and I could use the latest build of Windows 10 at full screen, something that was not possible with VirtualBox. This may be how I survey the various builds of the operating that appear before its final edition is launched later this year.
It seems that the Rename-Item commandlet in Powershell is a very useful tool when it comes to smarter renaming of files. Even text substitution is a possibility and what follows is an example that takes the output of the Dir command for listing the files in a directory and replaces hyphens with underscores in each one.
Dir | Rename-Item –NewName { $_.name –replace “-“,”_” }
The result is that something like the-file.txt becomes the_file.txt. This behaviour is reminiscent of the rename command found on Linux and UNIX systems, where regular expressions can be used like in the following example that has the same result as the above:
rename ‘s/-/_/g’ *
In both cases, you do need to be careful as to what files are in a directory for this though the wildcard syntax on Linux or UNIX will be more familiar who has worked with files via almost any command line. Another thing to watch in the UNIX world is that ** parses the whole directory structure and that could be something that is not wanted for much of the time.
All of this is a far cry from the capabilities of the ren or rename command used in the days of MS-DOS and what has become the legacy Windows command line. Apart from simple renaming, any attempt at tweaking a filename through substitution ended up with the extra string getting appended to filenames when I tried it. Thus, the Powershell option looks better in comparison.
The release of CentOS 7 stoked my curiosity so I gave it a go in a VirtualBox virtual machine. It uses GNOME Shell in classic mode so the feel is not too far removed from that of GNOME 2. One thing to watch though is that it needs at least version 4.3.14 of VirtualBox or the Guest Additions kernel drivers will not compile at all. That might sound surprising when you learn that the kernel version is 3.10.x and that for GNOME Shell is 3.8.4. Much like Debian production releases, more established versions are chosen for the sake of stability and that fits in with the enterprise nature of the intended user base. Even with that more conservative approach, the results still please the eye though attempting to change the desktop background picture managed to freeze the machine. Other than that, most things work fine.
Even so, there are unexpected things to be encountered and one that I spotted was that network connectivity needed to switched on every time the VM was started. The default installation gives rise to this state of affairs and it is a known situation with CentOS from at least version 6 of the distribution and is not so hard to fix once you know what to do.
What you need to do is look for the relevant configuration file in /etc/sysconfig/network-scripts/ and update that. Using the ifconfig command, I found that the name of the network interface. Usually, this is something like eth0 but it was enp0s3 in my case so I had to look for a file named ifcfg-enp0s3 and edit that. The text that is sought is ONBOOT=no and that needs to become ONBOOT=yes for network connections to start automatically. To do something similar from the command line, CentOS had suggested the following:
sed -i -e ‘s@^ONBOOT=”no@ONBOOT=”yes@’ ifcfg-enp0s3
The above uses sed to do an inline (and case insensitve) edit of the file to change the offending no to a yes, once you have dropped in the /etc/sysconfig/network-scripts/ directory. My edit was done manually with Gedit so that works too. One thing to add is that any file editing needs superuser privileges so switching to root with the su command and using sudo is in order here.
It appears that PROC SGPLOT and other statistical graphics procedures create image files even if you are creating RTF or PDF files. By default, these are PNG files but there are other possibilities. When working with PC SAS , I have seen them written to the current working directory and that could clutter up your folder structure, especially if they are unwanted.
Being unable to track down a setting that controls this behaviour, I resolved to find a way around it by sending the files to the SAS work directory so they are removed when a SAS session is ended. One option is to set the session’s working directory to be the SAS work one and that can be done in SAS code without needing to use the user interface. As a result, you get some automation.
The method is implicit though in that you need to use an X statement to tell the operating system to change folder for you. Here is the line of code that I have used:
x "cd %sysfunc(pathname(work))";
The X statement passes commands to an operating system’s command line and they are enclosed in quotes. %sysfunc then is a macro command that allows certain data step functions or call routines as well as some SCL functions to be executed. An example of the latter is pathname and this resolves library or file references and it is interrogating the location of the SAS work library here so it can be passed to the operating systems cd (change directory) command for processing. This method works on Windows and UNIX so Linux should be covered too, offering a certain amount of automation since you don’t have to specify the location of the SAS work library in every session due to the folder name changing all the while.
Of course, if someone were to tell me of another way to declare the location of the generated PNG files that works with RTF and PDF ODS destinations, then I would be all ears. Even direct output without image file creation would be even better. Until then though, the above will do nicely.
With a growing collection of photographic images, I often find myself making backups of files using copy commands and the data volumes are such that I don’t want to keep copying the same files over and over again so incremental file transfers are what I need. So commands like the following often get issued from a Linux command line:
cp -pruv [source] [destination]
Because this is in Linux, it the bash shell that I use so the switches may not apply to others like ssh, fish or ksh. For my case, p preserves file properties such as its time and date and the cp command does not do this always so it needs adding. The r switch is useful because the copy then in recursive so only a directory needs to specified as the source and the destination needs to be one level up from a folder with the same name there so as to avoid file duplication. It is the u switch that makes the file copy incremental and the v one issues messages to the shell that show how the copying is going. Seeing a file name issued by the latter does tell you how much more needs to be copied and that the files are going where they should.
What inspired this post though is my need to do the same in a Windows session and issuing xcopy commands will achieve the same end. Here are two that will do the needful:
xcopy [source] [destination] /d /s
xcopy [source] [destination] /d /e
In both cases, it is the d switch that ensures that the copy is incremental and you can add a date too, with a colon between it and the /d, if you see fit. The s switch copies only directories that contain files while the e one copies even empty directories. Using the d switch without either of those did not trigger any copying action when I tried so I reckon that you cannot do without either of them. By default, both of these commands issue output to the command line so you can keep an eye on what is happening and this especially is useful when ensuring that files are going to the right destination because the behaviour differs from that of the bash shell in Linux.
Though I use only the command line to do system updates, I still got system restart messages every time a new kernel version was installed. While they can be helpful, I actually prefer to be left to my own devices when it comes to restarting a system and I may have a something running at the time that I do not wish to interrupt.
In Ubuntu GNOME 13.10 and before, there was no sign of these messages so I decided to see if I could go nag free again. The responsible application is called Update Notifier and I tried seeing if I could remove it but that act has a major impact of the system so it was not a useful way to go.
As it happens, it is an application that starts up automatically at computer boot time but there was no sign of an entry for it in the Startup Applications Preferences screen (started using from the command line using gnome-session-properties). The for this is that there is flag called NoDisplay in the relevant autostart shortcut in /etc/xdg/autostart/ that stops it appearing in the aforementioned settings screen when set to true. The trick then is to set it to false and the following command (broken over two lines for sake of display and quotes could need replacing when you issue the command too) does the trick for all such hidden start-up applications:
sudo sed -i ‘s/NoDisplay=true/NoDisplay=false/g’
/etc/xdg/autostart/*.desktop
What the above does is that sed goes into every file and changes NoDisplay=true to NoDisplay=false in each file with the desktop extension. When that has completed, there are more entries in Startup Applications Preferences and Update Notifier can be deselected in order to stop it starting. Removing the relevant .desktop file would be a more permanent change but this one will do me, especially since no more of those pesky restart messages appear anymore. My regularity when it came to system updates meant that the update messages never appeared anyway and I tend to shut down my system at the end of every day so the updates will be picked up too so all should be well.