grabc, a CLI onscreen color grabber

[musher0]

Hello all.

I finally found it. This is a rare find, and it took me days to find it. First you have to
suspect such a thing exists, then find its name, Which is not obviously descriptve.
"Grab C" what? The C language? If you see what I mean. No, grab "c", "c" as in
"color"... Sure it was in a Debian repo all this time. But if nobody knows it's there...

In any case, this color picker works from terminal and returns the RGB number in
terminal. Big deal, you'll say: there are dozens of GUI color pickers at sourceforge,
at github, at the pinetools site, etc., etc. Plus Gimp and Mtpaint have one. -- You're
absolutely right.

Except with a console-based color picker like this grabc, you can readily control it with
say, xdotool, and incorporate the result in a script. And then if the background at that
place on the desktop is dark, you chose a contrasting light-colored icon for your utility,
on the fly.

Something like this, maybe:

Code: Select all

grabc 2> /dev/null | xsel -i

You drag the mouse on the desktop where your interesting color is, and click.
Then you issue this command:

Code: Select all

A="`xsel -o`";echo $A

Result:

#6c878e

Or similar use.

With the GUI-based color pickers, you can't do that. Or perhaps an expert dev could,
but it would be a complication.

So here you go: "grabc". A rare find for Puppyists. Please treasure it!

BFN.

[jplt3]

hello musher0,

i want to try this cli color grabber but 2 problems :
- the pet is not well named so it won't install
and this error , tested in bionicpup64

Code: Select all

grabc: error while loading shared libraries: libX11.so.6: wrong ELF class: ELFCLASS64

I reuploaded renamed.

[musher0]

Hello, jplt2.

The above is a 32-bit executable; it cannot run on a 64-bit system.
I think the source cannot be found anymore (to re-compile).

As to the packaging problem, I'll double-check. Thanks for mentioning it.

BFN.

[musher0]

Rebonjour jplt3.

About my packaging:
There is a quirk, it does not install as usual.

But I found the package in /root with the ending xz.
I was able to open it with Xarchiver.
Simply create a sub-directory to receive it and it will unpack there properly.

BFN.

[jplt3]

Ok i will test on a 32bit puppy...

[musher0]

Re-re-bonjour.

Hehe. I had to rename your package to grabc_1.1-2+b2_i386.pet locally to get it to install!

I think the down-loader on this forum is quirky. It changes some letters in the file names to
fit its understanding of things. Could it be based on WhineDose? Noooo!

Flash? Do you have an idea about this?

BFN.

[musher0]

I just PM'd the followiing to moderator Flash:

Hi, Flash.

Would you please have a look here?

Member jplt3 had problems downloading the pet file in that thread.
It seems the board's downloader re-interprets some characters in the file names wrongly.

Now since after download the name of the pet archive is not the same as the name of the
sub-dir in the archive itself, petget says it can't install it.

Any suggestion to users for correcting this forum behavior will be welcome.

TIA.

[OscarTalks]

Source can be found here
https://github.com/muquit/grabc
Note that version 1.0.2 is more recent than the 1.1 "orig" archived package held by Debian. I think perhaps they may have added some patches/modifications of their own and renumbered 1.0 as 1.1

[musher0]

Many thanks for that info, Oscar_Talks.

@jplt3: If you know how to do compilations, perhaps do one for the 64-bit Puppy?
As for me, I do not have a 64-bit machine any more.

Season's Greetings to all !

[Flash]

As far as I know, the forum software doesn't change filenames. If it doesn't like something in a post, it simply won't show anything. The whole post is blank. Maybe it's different for attachments. This would be the first time anyone has said anything about filenames being changed by the forum.

As for the PM musher0 sent me, he didn't include any specifics as to what was changed, so there's not much I can do with it.

[musher0]

As far as I know, the forum software doesn't change filenames. If it doesn't like something in a post, it simply won't show anything. The whole post is blank. Maybe it's different for attachments. This would be the first time anyone has said anything about filenames being changed by the forum.

As for the PM musher0 sent me, he didn't include any specifics as to what was changed, so there's not much I can do with it.

Hi Flash.

Thanks for responding.

Specifics:
The "+" character in the file name above becomes "%2" when saved as a download.
The user has to rename the file after download to what is displayed on the forum
to get the petget utility to install the pet archive properly.

IHTH.

Season's Greetings, BTW!

[MochiMoppel]

The "+" character in the file name above becomes "%2"

becomes "%2B", which is the hex value of '+', same as the better known "%20", which would be the hex value of 'space'.

The user has to rename the file after download to what is displayed on the forum
to get the petget utility to install the pet archive properly.

...which is an annoying and useless petget restriction. In principle a pet should install just fine even if the package name has been changed (by the user or as here by the server), but this is not permitted. It's a "security feature" I was told. Heaven only knows why.

I extracted only the binary grabc from the pet and it works fine in slacko5.6.
I still can't think of a scenario where this tool can be useful. There must be some.

I attach a text file (fake .gz extension) with almost all possible non-alphanumeric ASCII characters in its name.
You can check which of those get encoded when downloaded and which remain unchanged.
Original name: FILE !#$%&'()+,-[]^_`{|}~.txt.gz
Server delivers: FILE%20%21%23%24%25%26%27%28%29%2B%2C-%5B%5D%5E_%60.gz
Which is the encoded equivalent of FILE !#$%&'()+,-[]^_`.gz - Not exactly what I uploaded
Bottomline: Use only alphanumeric names. Underbars '_' are also safe.

[jplt3]

Thanks @OscarTalks for the github repo link.