Tweeting from the OS/2 Command Line ...Or Seeing Phantasmagoria With an OS/2 GUI Twitter Client/Browser Due to Inadequate Fonts.
By mere coincidence with a publishing of Data Center News article about rumors of a potential revival and/or re-engineering of OS/2 at IBM, I decided to experiment with that legacy, closed source, operating system and find out how it fared in a social network-centric ecosystem ...I wanted to know if OS/2 even possessed a mechanism (software, application) -other than the browser- to interact with Twitter -the Microblogging social platform. Consequently, if an OS/2 user could interact (or tweet) via a Twitter client, I wanted to know how "filtered" the information would display on the OS/2 client applications -as measured against existing closed source mainstream alternatives. My curiosity did not originate in a vacuum but was impulsed by an incident involving "modern" proprietary software. Evidently, OS/2 is the closest I will get to use a proprietary operating system and had curiosity for its capabilities to support the 140 character limit microblogging platform.
A few days ago, I recycled a tweet by a mutual Twitter follow. As is usual under my open source work environment, I made use of the default recycle/retweet symbol "♺", Unicode \u267A and HTML ♺ available in my Python-based Gwibber Twitter client under GNU/Linux Debian. As is often the case, I added a comment to an rather un-constructive tweet hoping to bring into the user's attention a degree of consciousness on the message. Being used to the un-encumbrances of an open source viewpoint and its associated fast paced development, little did I know that the pernicious element in the original tweet had been attributed to the retweeter/commentator: ...myself!. Open source has impulsed social media's creativity by networking an extraordinary volume of human beings -all of them a multiplicity of perspectives and using an heterogeneous volume of technology.
However, as is the case when large concentrations of individuals interact, misunderstanding are bound to occur. And I was reminded of the recently passed legislation in Arizona, sb 1070, that due to a relatively few individuals' transgressions a whole class of people that share physical characteristics and/or culture (association) are to submit to sanctioned civil rights abuses; these, in turn, are reminiscent of pre 1965 USA but are the norm in oppressive regimes. As a particular example of the latter comes to mind the sanctioned oppression in Mexico against the indigenous cultures, their resources, and their ancient languages like Nahuatl.
Well, retaking the Twitter incident, I realized soon I had been found "guilty" by retweeting (association) due to the fact that apparently not all the Twitter clients are enabled to display characters in Unicode and even may mangle HTML glyphs -like the recycle glyph above.
The proprietary nature of Twitter clients like TweetDeck have the added encumbrance of being executed on an proprietary platform that may impose additional restrictions on those Twitter client applications. Hence, the potential to misrepresent (and even obliterate) the form of characters, Unicode and otherwise, is always latent in the proprietary operating systems and/or applications used by those that consume our tweets. These latter, needless to say, may provoke unintended results -as the amplification of the insecurities and/or preconceived notions of some individuals consuming our tweets who may feel offended and/or threatened.
Accordingly, as in operating systems and browsers, those of us who support the evolution of software through our practice of open source face a dilemma. Either we bend backwards to satisfy the slow pace of development and/or willful lack of standards adherence that prevails among most of the proprietary software vendors, or we continue plowing forward bringing users of proprietary technologies with us, even if they kick and scream as we drag them outside their proprietary cave1 mind set. "Innovation in Open Source: let's not stifle its creative social impact with our own projections of phantasmagoria where there's none", I tweeted appropriately (and hope Arizona's sb 1070 supporters understand the analogy).
Where does one start to find out what potential Twitter client software solutions there may be for the OS/2? In the absence of an absolute authority to direct me to potential software to fulfill my curiosity, I looked at what open source software is available for GNU/Linux. Via a Linux Magazine article I found Twyt, a Python based command line Twitter client. Yes, in spite of the fact that many purported OS/2 enthusiasts dual boot with Windows -while pretending to despise it- and manifest an unabashed indifference towards GNU/Linux, open source has been instrumental to keep the OS/2 somewhat viable still in 2010.
Now, what volume of existing OS/2ers tweet so as to justify an decent Twitter client? I have not the slightest idea. While writing this blog entry I found that at least the main organization associated with monetizing an incarnation of OS/2 does tweet -via the Twitter API. Hence, has that organization (or umbrella organization that commercializes an OS/2 incarnation) developed an decent Twitter client for OS/2? Nah! Or at least I could not find relevant software sponsored by them. Nevertheless, in addition to OS/2 browser extensions like Twitbin for Firefox 2.0 and higher, there is qwit, a graphical twitter client for OS/2 1.0 r305 (for Qt 4.5.1 GA).
When 140 Characters is All You Need, the OS/2 Command Line Does it Better.
Ok, I added the OS/2 reference to Andrew Price's statement at the Twyt info Web page because its more than adequate. Accordingly, we will be installing Twyt in OS/2. We create a working directory v:\workspace to which we download the OS/2 Python port from OS/2 developer Paul Smedley's repository as well as relevant files -if the user does not already have those.
- python-2.6.4-os2-20100126.zip
- Supporting DLLs: gcc434.zip
- Supporting DLLs: libc-0.6.3-csd3.zip
- Zip archive decompressor: pkos2250.exe
Proceed to download Twyt and simplejson:
Verbatim: simplejson is the externally maintained development version of the json library included with Python 2.6
As before, please consider making a donation to reward the efforts of those developers that unselfishly make available their work.
We assume an hypothetical OS/2 user of the name Xiuhteuhctli having an OS/2 installed on drive V:. We also assume that, if needed, the zip format file de-compressor pkzip.exe has been extracted from the self-executable pkos2250.exe and placed at V:\OS2; then we are ready to operate on the other downloaded files:
We place the supporting DLLs at V:\OS2\DLL\. as follows:
PKZIP /EXTR GCC434 V:\OS2\DLL\.
PKZIP /EXTR LIBC-0.6.3-CSD3 *.DLL V:\OS2\DLL\.
To un-compress files of extension .gz we will be needing GNU Gzip for OS/2. I could not find Gzip for OS/2 that did not need the EMX environment. Accordingly, I am making available a mini EMX environment sufficient to complete the task at hand. Metztli-EMX.zip references the root drive where it is installed by the user. Hence, when user executes:
PKZIP /EXTR /DIR Metztli-EMX \.
Under the root drive where the user happens to execute the Metztli-EMX.zip, two(2) directories will be created (if not existent): \EMX and \OS2. Browsing \EMX the user will find a port of Unix utilities to OS/2 -including gzip.exe and others. And under \OS2 there will be the command file myEMX.cmd whose PATH directive statement assumes that the OS/2 PATH in user's OS/2 CONFIG.SYS ends in a semicolon ";"
Evidently, the user may modify file \OS2\myEMX.cmd to add a specific drive letter if more flexibility is desired. Nevertheless, I reiterate that all the operations will be performed relative to drive V: for the procedure under consideration.
After perpending the above, OS/2 user Xiuhteuhctli gets ready to set some environment variables by invoking \OS2\myEMX.cmd and the directives are echoed to the OS/2 command window screen:
We proceed to extract Python 2.6.x to drive V:\.
PKZIP /EXTR /DIR python-2.6.4-os2-20100126 V:\.
We rename python2.6.exe from the just decompressed resource under V:\PYTHON26\BIN to simply python26.exe
REN V:\PYTHON26\BIN\python2.6.exe python.exe
And we move python26.dll under V:\PYTHON26\BIN to the V:\OS2\DLL directory:
MV V:\PYTHON26\BIN\python26.dll V:\OS2\DLL\.
And place the following directives into a file myPython26.cmd that we place under V:\OS2; please note that directive number three(3) should be written all on a single line as in the illustration further down.
Code
PATH v:/python26/bin;%PATH% | |
SET PYTHONHOME=v:/python26 | |
SET PYTHONPATH=v:/python26/Lib;v:/python26/Lib/plat-os2knix;v:/python26/Lib/lib-dynload;v:/python26/Lib/site-packages; |
And executing the file from our OS/2 command line, we can see the updated environment variables echoed to our screen:
Typing python at our OS/2 command prompt we are greeted with an Python2.6 prompt:
[V:\WORKSPACE]python
(sample output
Python 2.6.4 (r264:75706, Jan 26 2010, 14:55:48)
[GCC 4.3.4] on os2knix
Type "help", "copyright", "credits" or "license" for more information.
>>>
User Xiuhteuhctli types help() to familiarize himself with Python environment options and subsequently types quit() to return to the OS/2 command prompt.
Subsequently, Xiuhteuhctli proceeds to test the Twyt TAR archive contents by entering:
tar -tvzPf twyt-0.9.2.tar.gz
Tar options (after the hyphen) enter tar --help for complete details:
- t: list contents
- v: be verbose
- z: un-compress simultaneously Gzip archive
- P: list absolute path leading character
- f: file to operate upon
...and proceeds to extract the compressed contents of the TAR archive with option:
- x: extract contents
Xiuhteuhctli changes directory to twyt-0.9.2 and uses the OS/2 EPM editor to modify the file setup.py:
start EPM setup.py
The directive in the file setup.py:
#!/usr/bin/env python
should be modified by adding .exe to env, as follows:
#!/usr/bin/env.exe
python
The modifications to setup.py are saved.
Xiuhteuhctli then proceeds to the file twyt under the scripts directory in the current location:
start EPM scripts/twyt
...and applies the same modification by adding .exe to env directive and saving -as above. Please note that without this modification, Python will not be able to find the env.exe executable found under /emx/bin/
The file INSTALL, contains instructions on how to install Twyt. It is important to execute our public domain Korn shell (found under /emx/bin) prior to installing Twyt and simplejson. Otherwise the OS/2 shell complains:
./setup.py install
(sample output)
SYS1041: The name . is not recognized as an internal or external command, operable program or batch file.
Hence Xiuhteuhctli invokes ksh.exe (that is found under /emx/bin) and subsequently follows again with the immediately previous command:
ksh
./setup.py install
Once Twyt is installed successfully, Xiuhteuhctli decreases his location by one directory level and extracts simplejson:
cd ..
tar -xvzPf simplejson-2.1.1.tar.gz
Similarly, he changes location to the newly created simplejson directory:
cd simplejson-2.1.1
As in prior occasions, Xiuhteuhctli proceeds to invoke EPM to edit setup.py relevant to simplejson as well as adds .exe to env:
Xiuhteuhctli then proceeds to install simplejson:
./setup.py install
Note that prior to installing, script(s) will likely download setuptools package -as indicated in the sample output below:
This script requires setuptools version 0.6c11 to run (even to display help). I will attempt to download it for you (from
http://pypi.python.org/packages/2.6/s/setuptools/), but you may need to enable firewall access for this script first.
In due time setuptools is installed and simplejson script(s) routine ends the process:
Xiuhteuhctli needs to complete one more procedure before being able to invoke Twyt and post his 140 character tweet. He moves twyt from V:\Python26\scripts to V:\Python26\bin (where it will be found by the shell) as follows:
mv V:\Python26\scripts\twyt to V:\Python26\bin\.
...and proceeds to open V:\Python26\bin\twyt with EPM for modifications. He replaces inaccurate directive:
#!V:/workspace/twyt-0.9.2
with accurate directive for his Python26 executable directory:
Code
#!V:/Python26/bin/python.exe |
Finally, Xiuhteuhctli is ready to test twyt functionality by invoking it with the -c option informational directive:
twyt -c
If you have followed Xiuhteuhctli this far, Paquilizcayolli! (Nahuatl for Congratulations!) We are ready to tweet our 140 character thoughts to the world! Please reference the more comprehensive Linux Magazine article on twyt.
Emerging From the Pernicious Depths of Narrow, Unquestioned, and/or Proprietary Perspectives.
If under OS/2 we open our browser and point it at Alan Wood’s Unicode Resources - Miscellaneous Symbols but the only glyphs we see are similar to little rectangular shapes, then please continue with instructions below.
When it comes to technology, even if proprietary, it is relatively easy to expand our horizons via Open Source by retrofitting our OS/2 with GNU FreeFont. According to its description (and my experience) it is Unicode-encoded and "contains a large set of symbol characters, both technical and decorative." As a concrete instance, I downloaded to my V:\WORKSPACE directory the TAR compressed archive freefont-ttf-20090104.tar.gz from the GNU FreeFont repository.
Once again, Xiuhteuhctli operates on the FreeFont true type font
TAR compressed archive to test its contents and verify that those will be extracted relative to current working location:
tar -tvzPf freefont-ttf-20090104.tar.gz
After the verification process, the extraction operation is executed:
tar -xvzPf freefont-ttf-20090104.tar.gz
Being a GNU/Linux command line masochist a la Debian, Xiuhteuhctli grudgingly proceeds to use the OS/2 WorkPlace Shell GUI to install the fonts. First, he clicks the OS/2 System icon; proceeds to select the System Setup icon; continues by clicking the Font Palette icon; then presses the Edit font... button; subsequently presses the Add... button. In the entry field of the ensuing dialog, the default source A:\ is replaced with the location of the GNU FreeFont directory, i.e., V:\Workspace\freefont-20090104\
Xiuhteuhctli presses Add... button and the Add New Font dialog appears. Xiuhteuhctli knows that the initial field on the left, labeled Font files, contains the GNU FreeFonts available to be added the default OS/2 drive location shown in the field immediately below and labeled: Copy font files to drive/directory. Accordingly, and for illustration purposes, Xiuhteuhctli selects the very first font file source with the mouse pointer and observes that the larger field on the right changes to reflect the Font names, exactly the label of the displaying field above.
In order to select the second, third, etc., font files, Xiuhteuhctli knows that the CTRL key must be kept pressed and the desired fonts selected with the mouse pointer. Hence as can be shown below, there are three font files selected (hilited) using the CTRL - pointer method.
To finish the adding fonts procedure, Xiuhteuhctli presses the Add button. All the selected (hilited) fonts are added to the V:\PSFONTS directory and the OS/2 must be rebooted for the changes to take effect.
After OS/2 reboot, please direct once again your browser to Alan Wood’s Unicode Resources - Miscellaneous Symbols The user should now be able to view more than three fourths(3/4) of the listed symbols on that page; whereas before the GNU FreeFonts, there where only mangled and/or square deformities.
"Now, if it were only that simple to expand the viewpoint of critically unexamined assumptions long held by humans!" Xiuhteuhctli exclaims.
Yes. There Is a Twitter Client for OS/2 (Not Appropriately) Named qwit.
Well, qwit comes compressed in a ZIP archive and can be easily de-compressed. What is somewhat problematic is the installation of the prerequisite sotware archived in WPI: The WarpIN general purpose installer for OS/2 is used for creating and installing archives and can be used to distribute almost any application.- Paul Ratcliffe.
Accordingly this is the software set that the OS/2 user should minimally need to install qwit for OS/2:
- WarpIN 1.0.19
- gcc-lib-4_4_2-20091204.wpi
- kLIBC runtime: libc-0_6_3-csd3.wpi
- QT4 runtime for OS/2: qt-lib-4_5_1-ga-noxwpdep.wpi
- And, of course, qwit -the qwit GUI Twitter client:
qwit-1.0-r305-os2test-20100211.zip
Additionally, please take care to install the software in the order listed above. Firstly, the OS/2 user successfully installs WarpIN, then all s/he has to do to install a package with an .wpi extension is double click on it; the WarpIN package manager will take care of installing it appropriately. Please note that although the XWorkplace archive ends in .exe it is processed by WarpIN as well.
Moreover, although the Qt4 runtime purportedly does not depend on XWorkplace, the WarpIN package manager refused to install it without a prior installation of XWorkplace.
Once the user gets to extract the qwit for OS/2 ZIP archive, an directory appropriately named qwit will be created. For instance, assuming that Xiuhteuhctli will extract it to the current directory, this is the command he would enter:
pkzip /extr /dir qwit-1.0-r305-os2test-20100211
Subsequently, the user would change her/his location to the newly created directory and type the executable to instanciate the GUI Twitter client for OS/2. That's it!
Why Not Enable Your OS/2 to Download YouTube Videos From The Command Line?
Since Python 2.6 Has Already Been Installed to The OS/2, all the user has to do is download youtube-dl: Download videos from YouTube.com -a Python program originally authored by Ricardo Garcia Gonzalez.
We may place the youtube-dl Python script at V:\Python26\bin\. and it would be found, similarly to the Twyt script, after we execute our public domain Korn Shell. But firstly youtube-dl should be modified analogously as we did for the Twyt and simplejson building procedures.
Hence, we open youtube-dl with our OS/2 EPM text editor:
EPM youtube-dl
We locate the she-bang directive at the very top of the Python script that originally reads:
#!/usr/bin/env python
And we add the .exe extension to env:
#!/usr/bin/env.exe python
And that's it! We move the script to either V:\emx\bin\. or equivalently:
mv youtube-dl V:\Python26\bin\.
We execute our shell:
ksh
And we download a sample file (all in a single line):
youtube-dl -o nahuatl-SesameStreet.flv http://www.youtube.com/watch?v=vAspreTYfvM
Well, in this case Xiuhteuhctli specifies the parameter -o to direct youtube-dl to rename the downloaded YouTube video to something humanly intelligible -as oppossed to the gibberish of the original YouTube names for the media resources.
As an aside, Xiuhteuhctli found the link to the video at the UniLang site -under Nahuatl resources by Mizton.
Oh! And the Hakuna Matata video snapshot earlier in the post was a recommendation/wish from a Twitter friend. Xiuhteuhctli downloaded it in similar fashion (again all in a single line):
youtube-dl -o Hakuna_Matata.flv http://www.youtube.com/watch?v=7Ai53uYyUzg
Evidently, I converted the downloaded *.flv files to *.mpg using the command:
ffmpeg -i SOURCE.flv -ab 56k -ar 22050 -b 500k -s 320x240 TARGET.mpg
Take special notice to include the bold italic k --without it the conversion will not include audio.
Evidently, SOURCE.flv represents the downloaded YouTube media resource and TARGET.mpg is the resultant conversion as hinted at the Web resource Convert .flv (Google Videos) to .mpg using ffmpeg
By the way, and to finish an lengthy post, you can download the ffmpeg video conversion utility from one of the sources for Unix/Linux to OS/2 ports listed above. And extract it as usual:
pkzip /extr /dir ffmpeg-svn-r22964-os2-20100426
Proceed to place the executable ffmpeg.exe to, say one of your OS/2 directories for executables, like V:\OS2
mv ffmpeg.exe v:\os2\.
Now you, the OS/2 user, may manipulate YouTube video files like Xiuhteuhctli. Again, Paquilizcayolli!
Conclussion: the design of OS/2, despite the inadequacy of the core essential development, continues to hold its own in 2010 against the so called "modern" proprietary operating systems and/or software applications. The porting of multiple purpose languages like Python by loose associations and independent developers like Paul Smedley continue to act as an extension mechanism for the endurance and viability of the OS/2.
1 Please read Plato's "Allegory of the Cave" if you are not familiar with the notion.
NOTE The views and/or opinions reflected here are my own and in no way necessarily reflect (by association) those of Metztli Information Technology as a whole and/or our business associates.
Suggestion code for commands entered at the OS/2 shell(s) prompt are provided on an AS-IS basis. Although due diligence has been applied, the information may not be accurate under all circumstances.
Consequently, please do not hold Metztli IT responsible if unforeseen effects are experienced. You are not obliged to use the information provided.
Metztli IT reserves the right to modify the procedure --including deleting the blog entry.