string | Technology Tales

Picking out a word from a string by its position using BASH scripting

28^th March 2023

My wanting to execute one command using the text output of another recently got me wondering about picking out a block of characters using its position in a space-delimited list. All this needed to be done from the Linux command line or in a shell script. The output text took a form like the following:

text1 text2 text3 text4

What I wanted in my case was something like the third word above. The solution was to use the cut command with the -d (for delimiter) and -f (for field number) switches. The following yields text3 as the output:

echo "text1 text2 text3 text4" | cut -d " " -f 3

Here, the delimiter is the space character, but it can be anything that is relevant for the string in question. Then, the "3" picks out the required block of text. For this to work, the text needs to be organised consistently and for the delimiters never to be duplicated, though there is a way of dealing with the latter as well.

Evoluent Vertical Mouse 3 Configuration in Ubuntu 9.10

31^st October 2009

On popping Ubuntu 9.10 onto a newly built PC, I noticed that the button mappings weren't as I had expected them to be. The button just below the wheel no longer acted like a right mouse button on a conventional mouse, and it really was throwing me. The cause was found to be in a file name evoluent-verticalmouse3.fdi that is found either in /usr/share/hal/fdi/policy/20thirdparty/ or /etc/hal/fdi/policy/.

So, to get things back as I wanted, I changed the following line:

<merge key="input.x11_options.ButtonMapping" type="string">1 2 2 4 5 6 7 3 8</merge>

to:

<merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 3 8</merge>

If there is no sign of the file on your system, then create one named evoluent-verticalmouse3.fdi in /etc/hal/fdi/policy/ with the following content and you should be away. All that's needed to set things to rights is to disconnect the mouse and reconnect it again in both cases.

<?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="info.capabilities" contains="input.mouse"> <match key="input.product" string="Kingsis Peripherals Evoluent VerticalMouse 3"> <merge key="input.x11_driver" type="string">evdev</merge> <merge key="input.x11_options.Emulate3Buttons" type="string">no</merge> <merge key="input.x11_options.EmulateWheelButton" type="string">0</merge> <merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge> <merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 3 8</merge> </match> </match> </device> </deviceinfo>

While I may not have appreciated the sudden change, it does show how you remap buttons on these mice, and that can be no bad thing. Saying that, hardware settings can be personal things, so it's best not to go changing defaults based on one person's preferences. It just goes to show how valuable discussions like that on Launchpad about this matter can be. For one, I am glad to know what happened and how to make things the way that I want them to be, though I realise that it may not suit everyone; that makes me reticent about asking for such things to be made the standard settings.

WARNING: The quoted string currently being processed has become more than 262 characters long…

20^th June 2007

This is a SAS error that can be seen from time to time:

WARNING: The quoted string currently being processed has become more than 262 characters long. You may have unbalanced quotation marks.

In the days before SAS version 8, this was something that needed to be immediately corrected. In these days of SAS character variables extending beyond 200 characters in length, it becomes a potential millstone around a SAS programmer's neck. If you run a piece of code like this:

data _null_;
    x="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
run;

What you get back is the warning message at the heart of the matter. While the code is legitimate and works fine, the spurious error is returned because SAS hasn't found a closing quote by the required position and the 262-character limit is a hard constraint that cannot be extended. There is another way, though: the new QUOTELENMAX option in SAS9. Setting it as follows removes the messages in most situations (yes, I did find one where it didn't play ball):

options noquotelenmax;

This does, however, beg the question as to how you check for unbalanced quotes in SAS logs these days; clearly, looking for a closing quote is an outmoded approach. Thanks to code highlighting, it is far easier to pick them out before the code gets submitted. The other question that arises is why you would cause this to happen anyway, but there are occasions where you assign the value of a macro variable to a data set one and the string is longer than the limit set by SAS. Here's some example code:

data _null_;
    length y $400;
    y=repeat("f",400);
    call symput("y",y)
run;

data _null_;
    x="&y";
run;

My own weakness is where I use PROC SQL to combine strings into a macro variable, a lazy man's method of combining all distinct values for a variable into a delimited list like this:

proc sql noprint;
    select distinct compress(string_var) into :vals separated by " " from dataset;
quit;

Of course, creating a long delimited string using the CATX (new to SAS9) function avoids the whole situation and there are other means, but there may be occasions, like the use of system macro variables, where it is unavoidable and NOQUOTELENMAX makes a much better impression when these arise.