Thank you Bram Moolenaar

 

xargs - The generic tool for arguments

    xargs is one of the most versatile tool used by command line warriors. There is a sort of aura around this command. Numerous videos are out there explaining the usage of this tool. The discussions below are to be taken as one for the entry level command line users. Kindly refer to the man pages for further advanced usage. In particular more information and its usage can be better appreciated from books and articles on shell programming, where a discussion on this is a mainstay.

    I will be using music files and c source files as examples wherever appropriate according to the easiness with which the underlying usage of xargs is more clear.

In the present directory as we start this discussion, we have the following files

music1.mp3
music2.mp3
music 3.mp3(notice the space in between music and 3)
music 4.mp3
big_program1.c
big_program2.c
big_program3.c

ls *.mp3 | xargs -t

echo music1.mp3 music2.mp3 music 3.mp3 music 4.mp3
music1.mp3 music2.mp3 music 3.mp3 music 4.mp3

    The output above is a little cryptic. Let us clear it first. If there is no other command to which xargs passes the arguments, the by default xargs pipes it to echo. The -t option is same as --verbose option with GNU extensions(by the way, I like GNU extensions for any program, they are more verbose and use the long form to extend  and explain what that particular option would do). By specifying the -t option, we are telling xargs to be more verbose in its activities. The result was that the xargs command took the output of ls and piped it to echo. We can see that exact executed by xargs in the first line of the output. The total result of the command is the output in the second line. All the arguments were passed on at once to the echo command.

    Now, let us change the above command such that the echo command is run on every argument. For that,

ls *.mp3 | xargs -t -n 1

echo music1.mp3
music1.mp3
echo music2.mp3
music2.mp3
echo music
music
echo 3.mp3
3.mp3
echo music
music
echo 4.mp3
4.mp3

    If we see the output, we met our task, partially. echo command is run on every argument. However, the file names with spaces in them have created a problem. By default, the delimiter for xargs is the space/blank character. To ensure that the above command works properly, we have to include the information of the delimiter in the xargs command, like so.


ls *.mp3 | xargs -t -n 1 -d'\n'

echo music1.mp3
music1.mp3
echo music2.mp3
music2.mp3
echo 'music 3.mp3'
music 3.mp3
echo 'music 4.mp3'
music 4.mp3

    Now, we see that the xargs command met our requirements. Now we are pretty confident that we can now pass on these xargs to other programs and are confident of them working properly. Let us now play the mp3s.


ls *.mp3 | xargs -t -n 1 -d'\n' mpg123

    This will now play all the mp3 files in alphanumeric order as listed by the default ls command, one after the another.

    Let us now take up the next key strength of xargs. xargs has the capability to spawn multiple processes so that arguments can be passed on to multiple instances of the program. For eg,

ls *.mp3 | xargs -t -n 1 -d'\n' -P 8 mpg123

    That was indeed funny, right. Seriously, that is a very wrong example to illustrate the parallel processing achieved by the above command. The above command starts multiple instances of mpg123, with all the instance playing an argument supplied. You can increase the argument for -P based on the number of files piped into the final command. Here you have all the four songs playing in parallel. The sound output might be interesting for music producers. For us listeners, nothing.

    Let us now consider a proper, practical example for this spawning of multiple processes,

ls *.c | xargs -t -n 1 -P 8 gcc

    The above command will run multiple instances of gcc at the same time and the compilation will happen in parallel on all the 3 files in the present directory. To do this kindly ensure that your programs can be compiled so and are stand alone and not dependent on each other being compiled already. Here we do not have the problem of file name containing spaces. If you are comfortable with

make -j 8

    For compiling your linux kernel, you know exactly what is happening here. The linux kernel is one of the greatest and practical examples for compiling sources in parallel. What a great feat. Kudos to all the kernel devs.

    With this, we come to the end of this gentle introduction to one of the most important tools for shell programming. The knowledge of xargs is a must for all shell programming aficionados.

    The standard thanks and regards to all the FLOSS users and devs. You people are great. Thanks again.

Buffers, Windows and tabs in vim/neovim

There are three concepts when it comes to viewing/editing files in vim.

Buffer:

When you open a file in vim the contents are loaded to RAM. This portion of the ram which has the contents of the file is the buffer. Now, this loading happens behind the scenes. It is no good if the file contents are in the buffer. We have to view it. That is what visual editors like vim are for. There are ways and means of editing files without having the contents of the file displayed on the screen. For that you can combine the power of ed and then the later front ends like grep and sed. So, now we are still at a stage where vim has loaded the file into memory and named that block of memory with a name taken from the file name itself. This buffer name can be used in moving around buffers when we have multiple buffers.

When you create an empty buffer, vim allocates a certain amount of the RAM for the buffer. If you write this content to a file then the contents are saved. If you delete the buffer without saving it then all your content created in this buffer is out in the ether.

For playing with buffers vim provides commands starting with :buffer. It follows the object, action on the object philosophy of the other vim commands.

When you shift from one buffer to another using the buffer next command or similar, vim prompts you to save the present buffer to file. This can be overridden with settings in the vim config file.

Window:

This is the area where the contents of the buffer is displayed to the user. After loading the file into the buffer, vim then reads the contents of the buffer and displays it on the screen for the user's viewing pleasure. A full screen of content, which was a big deal in the good old days. To display the file vim creates a window. The file contents are displayed within this window. Okay, you have been editing a single file for many days. Now, you want to refer another file. So you now go ahead and open it up with :e file2

You are in for a shocker, the screen is now showing only the contents of file2. As we have already clarified, a window is the place where vim displays the contents of the file. In the present case we have only one window. So, when you requested vim to open a second file, vim agreed and showed the contents on the solitary windows. To show that vim had to clear the screen and load up the buffer which was the contents read in from file2.

The situation here is we are having one window and two buffers, as such vim can display only one buffer while the other is still loaded and available with vim read to be displayed when asked for. You can ask to bring the buffer contents of file1 to the fore by using appropriate :buffer command. But, instead a more elegant way of viewing both files side by side would be to create another window. This will reduce the screen estate available for each windows. if you open two windows then both share 50% of the screen and so forth.

Ctrl-W v    opens a new window and splits the screen into half vertically. Now you can open file1 in the left window and file2 in the right window. Now there are two buffers and two windows displaying the respective buffer. What if I open the same file in both the windows, well all your editing activities in one window will reflect in the second window also. try it. Because you are editing the same buffer.

To end the discussion about windows, when you close a window, the buffer is not offloaded from memory. It is still there within vim. You have to delete the buffer using the respective command to instruct vim to offload the buffer from memory.

Tab:

Tabs are the masters of vim windows. Every tab has access to the full screen. Withing tabs you create windows as explained above. In the above example there was only one tab which is started by default. Every tab can have multiple windows. When you close a tab you close all the windows in that tab. tabs are good when you want all your files to use the complete screen of your monitor. Whenever a new tab is created it is started with exactly one window. If you want to view file1 and file2 using the full screen estate of your monitor and move between them then, the :tab command is the way to go. The disadvantage is that you cant see the file side by side.

When you close a tab, all the windows within that tab are closed. But all the buffers you were viewing in that tab within their respective windows are still in memory. You have to delete the buffers to remove them from memory.

 Of course, when you quit vim, all the buffers are closed and any changes which you have done to the buffers, will be queried for saving.

In summary, we see that there is no one single strategy which works for and individual. And for every individual, the strategy depends on the task/s at hand. So, dont be very harsh on your preferences. You will be losing out on the most important aspect of vim, ie, "situational editing"

Well, What is on my raspberry pi 4

The first thing I install is my client for the cloud based notes application. I use simplenote. It has the advantage that it is available on all the major platforms. There is a terminal client called sncli. This is my go to client.
The next thing is to install terminology for the terminal. After trying out many, I observed that terminology is the fastest on the pi.
i3 window manager. I cannot live without it. None of my Gnu/Linux installations is complete without this. It is lightweight, easily configurable and simple.
For the browser, since I have started using computers I have sided with Firefox. I am at home with this browser. I install noscript, ublock, privacy badger and dark reader plugins. I like it. It has always met my expectations.
For the application launcher i go with rofi. The run menu is shown in a small window in the bottom left corner of my monitor.
For searching on the command line I use ddgr(DuckDuckgo client for the terminal) and surfraw. After installing surfraw I install a small script called menu-sufraw available on github. This integrates beautifully with rofi. Must try.
For the office suite, My choice was OpenOffice before it went to the butcher's table with the Apache foundation. Now it is libreoffice. I like it. It gets the job done.
For my text editor, wait, wait, I use both Neovim and Doom emacs as demanded by the situation. I use emacs with the client/server model. It is quick and very snappy to start and to work.
Feh for my wallpaper needs.
There is one more plugin which I install on firefox, it is called play-with. This I combine with mpv. We now have an awesome combination for playing streaming content on the pi. For this configuration to work there is one more piece of software required and that is youtube-dl. A beautiful example of the unix philosophy working for the modern age of the internet.
Not to forget that all the apps are in dark mode, if available. I like the dark mode. It has been excellent for my eyes. Even now when firefox flashes before loading a tab, I close my eyes for a while. Thank you, Apple, only for bringing the dark mode into vogue.
My hardware setup is already discussed in one of my previous posts.
font-awesome for that "graphics" in the terminal.
d2code for the font, wherever possible. I like its legibility.
I use i3status showing the date, time, empty space, processor speed and the temperature.

Thanks to all the devs/users of all the freedom software. My respect to one and all without which this post wouldn't exist.