TOPIC: TAR
Customising the nano editor using a personal configuration file stored in your home directory
For a long time, I had not realised that the nano editor could be customised, and a look at /etc/nanorc on a Linux system will show what is possible. However, editing that file will not yield such permanent alterations, given the vagaries of system and package updates. Thus, the option of having a .nanorc file in your home directory has its uses. Here then are some settings that you can specify in this file to make the user-friendly editor even more useful:
set softwrap
By default, nano does not wrap long lines. For a time, I overlooked this, only for its use as a website content editor to change that. Adding this setting will wrap the long line to save some scrolling time and aid in getting a fuller picture of its contents. There is breaklonglines too, even though that adds hard breaks, which means that you get carriage returns added to your file, not always a desirable outcome.
set atblanks
To get the line wrapping to use spaces as a delimiter, define this setting. After that, you will not want to see words being broken up by line breaks.
set linenumbers
Many editors have line numbers which help to navigate files. Although nano has a shortcut for going to a particular line, line numbers are not set by default. This setting sets that to rights.
set indicator
Following on from the above, adding a bar on the right-hand side with the appearance of a scroll bar seen in other applications has its uses for seeing where you are in a file. That can help with orientation.
set nonewlines
By default, nano adds an extra blank line at the bottom of any file that it edits. While this may have uses for display using the cat command when an extra line avoids messing up where the command line prompts appear and having a ready location to add content at the end of a file, it always has looked odd to me. This setting turns off that behaviour to make things work like they do elsewhere.
set tabstospaces
In many editors, there is an option to turn tabs into spaces (SAS Enterprise Guide and entimICE are two examples that come to my mind as I write these words), and this will do the same within nano. That could be useful when making everything consistent within a file, especially after copying in code from elsewhere.
set tabsize 4
A recent discussion with colleagues at work revealed that we all indent code a little differently. The numbers of spaces had become the major differentiator, and the client had no standard for this. While four would be my choices, others have two, which is where this setting is helpful when it is used with the tabstospaces one described above.
This list is but a subset of what is on offer, and that is why the file mentioned at the start is well worth perusing. For all too long, I had not realised what was possible until editing of Markdown files caused me to wonder if nano could be made even better than it was when the default settings were active.
Safe file copying methods for cross platform SAS programming
Not so long ago, I needed to copy a file within a SAS program, only to find that an X command would not accomplish the operation. That cast my mind back to file operations using SAS in order to be platform-independent. Thus, I fell upon statements within a data step.
Before going that far, you need to define filename statements for the source and target locations like this:
filename src "<location of source file or files>" lrecl=32767 encoding="utf-8";
filename dst "<target location for copies>" lrecl=32767 encoding="utf-8";
Above, I also specified logical record length (LRECL) and UTF-8 encoding. The latter is safer in these globalised times, when the ASCII character set does not suffice for everyday needs.
Once you have defined filename statements, you can move to the data step itself, which does not output any data set because of the data _null_ statement:
data _null_;
length rc msg $ 300;
rc = fcopy('src','dst');
if rc ne 0 then do;
msg = sysmsg();
putlog "ERROR: FCOPY failed rc=" rc " " msg;
end;
else putlog "NOTE: Copied OK.";
run;
The main engine here is the fcopy function, which outputs a return code (rc). Other statements like putlog are there to communication outcomes and error messages when the file copying operation fails. The text of the error message (msg) comes from the sysmsg function. After file copying has completed, it is time to unset the filename statements as follows:
filename src clear;
filename dst clear;
One thing that needs to be pointed out here is that this is an approach best reserved for text files like what I was copying when doing this. When I attempted the same kind of operation with an XLSX file, the copy would not open in Excel afterwards. Along the way, it had got scrambled. Once you realise that an XLSX file is essentially a zip archive of XML files, you might see how that could go awry.
ERROR: This range is repeated, or values overlap: - .
This is another posting in an occasional series on SAS error and warning messages that aren't as clear as they'd need to be. What produced the message was my creation of a control data set that I then wished to use to create a data-driven (in)format. It was the PROC FORMAT step that issued the message, and I got no (in)format created. However, there were no duplicate entries in the control data set as the message suggested to me, so a little more investigation was needed.
What that revealed was that there might be one variable missing from the data set that I needed to have. The SAS documentation has defined FMTNAME, START and LABEL as compulsory variables, with each of them containing the following: format name, initial value and displayed value. My intention was this: to create a numeric code variable for one containing character strings using my data-driven format, with then numbers specified within a character variable as it should be. What was missing then was TYPE.
This variable can be one of the following values: C for character formats, I for numeric informats, J for character informats, N for numeric formats and P for picture formats. Due to it being a conversion from character values to numeric ones, I set the values of TYPE to I and used an input function to do the required operations. The code for successfully creating the informat is below:
proc sql noprint;
create table tpts as
select distinct "_vstpt" as fmtname,
"I" as type,
vstpt as start,
vstpt as end,
strip(put(vstptnum,best.)) as label
from test
where not missing(vstptnum);
quit;
proc format library=work cntlin=tpts;
run;
quit;
Though I didn't need to do it, I added an END variable too for the sake of completeness. In this case, the range is such that its start and end are the same and there are cases where that will not be the case, though I am not dwelling on those.
A fallback installation routine?
In a previous sustained spell of Linux meddling, the following installation routine was one that I encountered rather too often when RPM's didn't do what I required of them (having a SUSE distro in a world dominated by a Red Hat standard didn't make things any easier...):
tar xzvf progname.tar.gz; cd progname
The first part of the command extracts from a tarball compressed using gzip and the second one changes into the new directory created by the extraction. For files compressed with bzip use:
tar xjvf progname.tar.bz2; cd progname
The command below configures, compiles and installs the package, running the last part of the command in its own shell.
./configure; make; su -c make install
Yes, the procedure is a bit convoluted, but it would have been fine if it always worked. My experience was that the process was a far from foolproof one. For instance, an unsatisfied dependency is all that is needed to stop you in your tracks. Attempting to install a GNOME application on a KDE-based system is as good a way to encounter this result as any. Other horrid errors also played havoc with hopeful plans from time to time.
It shouldn't surprise you to find that I will be staying away from the compilation/installation business with my main Ubuntu system. Synaptic Package Manager and its satisfactory dependency resolution fulfil my needs well and there is the Update Manager too; I'll be leaving it for Canonical to do the testing and make the decisions regarding what is ready for my PC as they maintain their software repositories. My past tinkering often created a mess, and I'll be leaving that sort of experimentation for the safe confines of a virtual machine from now on...