[PLUG] PLUG N: CLI access to clipboards, xdg-foo, and more

[JP Vossen <jp@jpsdomain.org>]

I wanted to follow-up on several discussions we had last night at PLUG N.


For details on "bash" vs "dash" see my PLUG preso at 
http://princessleia.com/plug/2008-JP_bash_vs_dash.pdf.


The 'checkbashisms' script is supplied on Debian/Ubuntu in the 
"devscripts" package, or here at the badly spelled 
http://sourceforge.net/projects/checkbaskisms/ project.


Longer items:

1) reading and writing the "clipboard" under Linux and Windows
2) 'gnome-open' and 'xdg-open'
3) The x86 architecture; backwards compatibility thereof


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First, we were discussing reading and writing the "clipboard" under 
Linux and Windows.

For Linux, I use 'xsel' tool/package with the following aliases that 
Just Do What I Mean, read the man page for more:
	alias getclip='xsel -b'
	alias putclip='xsel -bi'

For Windows, I use gclip.exe and pclip.exe from the awesome UNXUtils at 
http://unxutils.sourceforge.net/.  See also many previous discussions in 
the archives, especially 
http://lists.netisland.net/archives/plug/plug-2007-09/msg00280.html.

CPAN (and in particular ActivePerl for Windows) also has 
http://search.cpan.org/~jdb/Win32-Clipboard/.  The following is the code 
I use, but note I haven't updated my ActivePerl or Win32::Clipboard in 
forever, so this may be obsolete now.

### READ
use Win32::Clipboard;  # Import the clipboard module
my $cboard  = Win32::Clipboard::GetText(); # (Have to) Read entire 
clipboard contents
$cboard =~ s/\r//g; # Remove odd CRs ("\r"), if any, the clipboard sticks

### Write (This is especially ugly, I wrote this many, many years ago)
### I write the output to a temp file (no, I don't remember why.  It 
seemed like a good idea at the time).
### Then:
use Win32::Clipboard;                # Import the module
open (TMPFILE, "$tempfile") || die "$myname: error opening temp file 
$tempfile = $!";

binmode (TMPFILE);                   # Put into BINMODE so we don't mess 
with line termination
undef ($/);                          # Undefine the input line 
terminator so we grab the whole thing
my $cboard = <TMPFILE>;              # Grab it
Win32::Clipboard::Set("$cboard");    # Send it to the clipboard

close (TMPFILE);                     # Close, then delete (unlink) the 
temp file
unlink("$tempfile") || die "$myname: Could not delete temp file 
$tempfile: $!\n";



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Second, I had mentioned 'gnome-open' and Rich countered with 'xdg-open'.

gnome-open - Open files and URLs using the GNOME file handlers
xdg-open - opens a file or URL in the user's preferred application

I think Rich wins, because his solution is slightly shorter and more 
portable.  :-)

When you spend a lot of time at the command line, the ability to open 
things in the GUI, like 'xdg-open path/to/some.pdf' is pretty cool.

See also:
	1) 'start /?' on Windows.
	2) http://portland.freedesktop.org/wiki/   # xdg-stuff...



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In talking about x86 "real" vs "protected" mode, and the backwards 
compatibility that allows, Rich suggested that DOS would probably boot 
on your brand new 8 core, 8G RAM hypersuperduper system.

Damn if he wasn't right.

In literally 30 seconds, I just grabbed a USB floppy drive, a 720K (!!!) 
Zenith DOS 3.21 boot floppy (the oldest I had handy, and how scary is 
THAT statement) and booted a Dell Inspiron 1525 laptop.  And. It. Just. 
Worked.  I am sitting at an A> prompt.

I tried a Dell R210, but it did not see the floppy drive and I did not 
mess with the BIOS.  = Fail, but probably for BIOS and not CPU/MB reasons

I tried a Dell PE-650 and it saw the floppy, and I messed with the BIOS 
to put the floppy first in the boot order, but it didn't see the OS and 
kept trying to PXE boot the NIC.  = Fail, but probably for BIOS and not 
CPU/MB reasons

In VMware Workstation 7.x, my MS-DOS 6.22 started with DHCP networking 
just fine ("C:>").  My DR-DOS 7.0.3 started with no networking (I never 
configured it), as well ("C:>").  FreeDOS 1.0 failed to start with a 
bunch of errors ending in "EMM386 - unable to continue" but when I chose 
a different start option it also worked fine ("C:>").

At that point I'd spent enough time on this and I stopped...

Though you know what'd be really funny?  Booting a Macbook with that 
drive and seeing what happens...  I'd assume nothing will happen as the 
Mac BIOS is probably too different and not looking for floppies.  Still...

Later,
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug