You are not logged in.

#26 2021-02-15 18:21:55

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

sleekmason wrote:
grep file:///  | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line ~/.local/share/recently-used.xbel;

Lint accepted the line above as working

And that's exactly the sort of errors shellcheck et al. cannot fix.
About useless use of cat in conjunction with grep:

cat somefile | grep something

is the same as

grep something somefile

Any more pipes that follow are not affected by this argument.
-------------
So, to make it very clear:

cat ~/.local/share/recently-used.xbel | grep file:///

can be replaced with ... ?
-------------
Btw, I'd quote 'file:///' just to be on the safe side.
And btw, the last slash denotes the root directory - is this the logic you're after?
It probably won't hurt because all paths are expanded to absolute paths, but still...
If you want to express the path "$HOME/somefile" with this locator thingy, it's "file://$HOME/somefile", which expands to "file:///home/sleekmason/somefile" -  so, you see, the last slash denotes the root directory.
Just saying.


Give to COVAX! Here or here. (explanation)

Offline

#27 2021-02-15 21:23:44

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

ohnonot wrote:
sleekmason wrote:
grep file:///  | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line ~/.local/share/recently-used.xbel;

Lint accepted the line above as working

And that's exactly the sort of errors shellcheck et al. cannot fix.
About useless use of cat in conjunction with grep:

cat somefile | grep something

is the same as

grep something somefile

Any more pipes that follow are not affected by this argument.
-------------
So, to make it very clear:

cat ~/.local/share/recently-used.xbel | grep file:///

can be replaced with ... ?
-------------
Btw, I'd quote 'file:///' just to be on the safe side.
And btw, the last slash denotes the root directory - is this the logic you're after?
It probably won't hurt because all paths are expanded to absolute paths, but still...
If you want to express the path "$HOME/somefile" with this locator thingy, it's "file://$HOME/somefile", which expands to "file:///home/sleekmason/somefile" -  so, you see, the last slash denotes the root directory.
Just saying.



This took a minute.
So, the file has to be listed before the options desired?

grep "file:///" ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

So then redundant so:

grep file ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

*Edit - So, here is the completed script with all of the errors from lint corrected:

#!/bin/sh
echo "<openbox_pipe_menu>"
files=$(
grep file ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line; 
do  
file="$line"
name=$(echo "$file" | sed 's,.*/,,' | sed 's/%20/ /g')
echo "<item label=\"$name\" icon=\"/usr/share/icons/gnome/32x32/apps/accessories-text-editor.png\">
		<action name=\"Execute\"><command>xdg-open $line</command></action>
	</item>"
done);
echo "$files"
echo "<separator />"
echo "<item label=\"Clear Recents\">
		<action name=\"Execute\"><command>rm ~/.local/share/recently-used.xbel</command></action>
	</item>"
echo "</openbox_pipe_menu>"

Last edited by sleekmason (2021-02-15 22:08:56)

Offline

#28 2021-02-16 02:59:55

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

sleekmason wrote:

So, the file has to be listed before the options desired?

grep "file:///" ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

So then redundant so:

grep file ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

File? options?
Just a moment, you know what grep does, right?
It's looking inside some file ( in this case ~/.local/share/recently-used.xbel ) for a line (or lines) which contains some pattern.

In your first snippet it will output any line which contains 'file:///' and in the second any line with 'file'. (It doesn't matter what significance the slashes might have, it's just a pattern to search for.)

Maybe in your case the only lines with 'file' just happens to be the lines you're looking for with 'file:///', but generally it's best to make the pattern as specific as possible to avoid getting false positives. ( For that matter, in your case the search pattern could just as easily be '<bookmark href=' ) And as ohnonot says, it's highly advisable to put the pattern inside quotes, especially if it's a regular expression with symbols like * that the shell might try to (mis)interpret.

Last edited by johnraff (2021-02-16 04:15:48)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#29 2021-02-16 11:55:44

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

johnraff wrote:
sleekmason wrote:

So, the file has to be listed before the options desired?

grep "file:///" ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

So then redundant so:

grep file ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

File? options?
Just a moment, you know what grep does, right?
It's looking inside some file ( in this case ~/.local/share/recently-used.xbel ) for a line (or lines) which contains some pattern.

In your first snippet it will output any line which contains 'file:///' and in the second any line with 'file'. (It doesn't matter what significance the slashes might have, it's just a pattern to search for.)

Maybe in your case the only lines with 'file' just happens to be the lines you're looking for with 'file:///', but generally it's best to make the pattern as specific as possible to avoid getting false positives. ( For that matter, in your case the search pattern could just as easily be '<bookmark href=' ) And as ohnonot says, it's highly advisable to put the pattern inside quotes, especially if it's a regular expression with symbols like * that the shell might try to (mis)interpret.

Okay, so after all is said and done, What is the correct line to use to insure everything is groovy? (kinda at a point where I need to see something correct here).

Offline

#30 2021-02-16 18:58:04

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

ohnonot wrote:

And btw, the last slash denotes the root directory - is this the logic you're after?
It probably won't hurt because all paths are expanded to absolute paths, but still...
If you want to express the path "$HOME/somefile" with this locator thingy, it's "file://$HOME/somefile", which expands to "file:///home/sleekmason/somefile" -  so, you see, the last slash denotes the root directory.
Just saying.

You understand that this remark was completely independent from the "useless use of cat" (aka UUOC) discussion?

sleekmason wrote:

Okay, so after all is said and done, What is the correct line to use to insure everything is groovy? (kinda at a point where I need to see something correct here).

I slightly lost the overview; what is the goal again? Is the script not working? If so, how exactly is it not working?


Give to COVAX! Here or here. (explanation)

Offline

#31 2021-02-16 19:39:33

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

ohnonot wrote:
ohnonot wrote:

And btw, the last slash denotes the root directory - is this the logic you're after?
It probably won't hurt because all paths are expanded to absolute paths, but still...
If you want to express the path "$HOME/somefile" with this locator thingy, it's "file://$HOME/somefile", which expands to "file:///home/sleekmason/somefile" -  so, you see, the last slash denotes the root directory.
Just saying.

You understand that this remark was completely independent from the "useless use of cat" (aka UUOC) discussion?

sleekmason wrote:

Okay, so after all is said and done, What is the correct line to use to insure everything is groovy? (kinda at a point where I need to see something correct here).

I slightly lost the overview; what is the goal again? Is the script not working? If so, how exactly is it not working?

Lol, Purely academic at this point.  The line worked as is. Lint wanted it corrected, so I attempted to correct it.

The original line was:

cat ~/.local/share/recently-used.xbel | grep file:///  | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line;

My brilliant deduction of what you posted:

grep file ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line; 

And my eventual completion that johnraff nixed.

#!/bin/sh
echo "<openbox_pipe_menu>"
files=$(
grep file ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line; 
do  
file="$line"
name=$(echo "$file" | sed 's,.*/,,' | sed 's/%20/ /g')
echo "<item label=\"$name\" icon=\"/usr/share/icons/gnome/32x32/apps/accessories-text-editor.png\">
		<action name=\"Execute\"><command>xdg-open $line</command></action>
	</item>"
done);
echo "$files"
echo "<separator />"
echo "<item label=\"Clear Recents\">
		<action name=\"Execute\"><command>rm ~/.local/share/recently-used.xbel</command></action>
	</item>"
echo "</openbox_pipe_menu>"

So, Please show me what would/should be correct for the line in question.  I am at the point where for me to understand, I need to see something concrete.

Last edited by sleekmason (2021-02-16 19:42:03)

Offline

#32 2021-02-17 00:43:33

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

I don't think the replacement of 'file:///' with 'file' achieved anything - just made the script less robust.

Try going back to this:

grep 'file:///' ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line; 

The rest of the script looks as if it would work, although I can see some places where the code could be simplified.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#33 2021-02-17 13:57:23

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

johnraff wrote:

I don't think the replacement of 'file:///' with 'file' achieved anything - just made the script less robust.

Try going back to this:

grep 'file:///' ~/.local/share/recently-used.xbel | tail -n15 |  cut -d "\"" -f 2 | tac | while read -r line; 

The rest of the script looks as if it would work, although I can see some places where the code could be simplified.

Good! Thank you. 

So, Why would it be less robust if the path is to the same file? (seems like it should be the opposite).

In your first snippet it will output any line which contains 'file:///' and in the second any line with 'file'. (It doesn't matter what significance the slashes might have, it's just a pattern to search for.)

Maybe in your case the only lines with 'file' just happens to be the lines you're looking for with 'file:///', but generally it's best to make the pattern as specific as possible to avoid getting false positives.

So basically, if it was a script with paths to multiple files, without using 'file:///',
the script wouldn't separate them out?

I can certainly leave this go now either way.  Hope you guys are not getting too upset with my questions. I learn this way much better. Diving into a specific area, and then back out to something simplified.

I have been "fixing" all of my scripts.  Found pep8 for lint.and am now working on a couple of python scripts as well. (No Tabs!)

Offline

#34 2021-02-18 02:29:44

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

sleekmason wrote:
johnraff wrote:

I don't think the replacement of 'file:///' with 'file' achieved anything - just made the script less robust.

So, Why would it be less robust if the path is to the same file? (seems like it should be the opposite).

"Robust" in the sense of less likely for grep to produce false positives. How about if ~/.local/share/recently-used.xbel contained something like "file manager"? Then grep 'file' would output that line: not what you want. The "recent files" script is searching through recently-used.xbel for references to recently used files. If you look in that file you'll see that it's a kind of xml, and all the references you want are like this (eg at the end of my file):

<bookmark href="file:///etc/NetworkManager/NetworkManager.conf" added="2021-02-18T01:14:00Z" modified="2021-02-18T01:14:00Z" visited="2021-02-18T01:14:01Z">

If you look for 'file:///' then there's a good chance of fishing out the information you want. 'href="file:///' would work too, or even '"file:///[^"]*"'
Just as an experiment try:

grep -o '"file:///[^"]*"' ~/.local/share/recently-used.xbel

(see man grep)

But parsing xml (or xbel) like this, line-by-line with grep, is inherently unreliable, because (among other reasons) line-breaks are allowed anywhere in xml.

Actually, this script is somewhat familiar to me. I based something on the same script in the OpenBox wiki back in the CrunchBang era, tweaked it a bit (can't find a link to that version), and Corenominal added it to the #! pipemenus. But around 2010 I switched to using awk for processing the data, because it didn't have to rely on line-breaks to split up the data. Archlabs borrowed and improved on that version. For BunsenLabs, @twoion rewrote the whole thing in lua so now it parses the xml correctly. cool

Well, at the start of this thread you had a script which was working, and just wanted to add icons to it. That turned out to be a bit of a rabbithole!


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#35 2021-02-18 03:21:56

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: [Solved] Icons in pipe menus

@johnraff is there not an xml parsing tool available from the command line? An XML file is nothing more than a dictionary data set, after all.

Offline

#36 2021-02-18 06:30:56

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

^Yes there are xml parsing tools which a shell script could invoke, eg xmlstarlet or xpath (libxml-xpath-perl).

xpath -q -e  '/xbel/bookmark/@href' ~/.local/share/recently-used.xbel

produces:

 href="file:///home/john/.config/bunsen/autostart"
 href="file:///home/john/text/TODO"
 href="file:///home/john/text/notes"
etc

Or:

xmlstarlet sel --template --match  '/xbel/bookmark' --value-of '@href' -n ~/.local/share/recently-used.xbel

for

file:///home/john/.config/bunsen/autostart
file:///home/john/text/TODO
file:///home/john/text/notes
etc

And using grep, sed, regular expressions et al is indeed severely deprecated: https://stackoverflow.com/a/1732454

Last edited by johnraff (2021-02-18 06:50:23)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#37 2021-02-18 07:33:59

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

^ I sometimes use xmllint.

@sleekmason  (and to whomever it may concern), I took some time and rewrote your recent script.
It is well commented.

Quality control and comments - that's how you get from a oneliner to over 100 lines... roll

Since pipemenus are executed each time you activate the menu item, I took great pains to make it fast.
As it converts required icons, the first execution might be slower, but later it should be near-instant.

Last edited by ohnonot (2021-07-04 09:24:41)


Give to COVAX! Here or here. (explanation)

Offline

#38 2021-02-18 08:12:47

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

@ohnonot you tested this on Arch? Problem with xmllint on Debian Buster is that libxml2-utils up to 2.9.9 outputs all the values on one line. I think 2.9.10 on Bullseye will add linebreaks so mapfile will work.
Earlier xmllint is probably fine if you only need a single value, but maybe switch to xpath? It requires libxml-xpath-perl but that's not so big.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#39 2021-02-18 15:17:03

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,057

Re: [Solved] Icons in pipe menus

Nice. I asked because I vaguely remembered the old corenominal script. I believe that I got it working at one point or another but discarded it as useless cruft later.

Offline

#40 2021-02-18 16:18:53

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

johnraff wrote:

Actually, this script is somewhat familiar to me. I based something on the same script in the OpenBox wiki back in the CrunchBang era, tweaked it a bit (can't find a link to that version), and Corenominal added it to the #! pipemenus. But around 2010 I switched to using awk for processing the data, because it didn't have to rely on line-breaks to split up the data. Archlabs borrowed and improved on that version. For BunsenLabs, @twoion rewrote the whole thing in lua so now it parses the xml correctly. cool

Well, at the start of this thread you had a script which was working, and just wanted to add icons to it. That turned out to be a bit of a rabbithole!

Yup!  Forgot all about the original reason for the thread. Good history here. smile  Appreciated the detailed explanation for why 'file:///' is necessary.  I found the script on one of the old pages for openbox setup . .  I think.  I had grabbed about 4-5 scripts, but only two of them worked . (I see why now).

ohnonot wrote:

@sleekmason  (and to whomever it may concern), I took some time and rewrote your recent script.
It is well commented, so just take a look:

This. Is. Awesome! What a neat script!  Thank you for taking the time to comment everything.  Really good stuff for me. smile

No, it doesn't work because of the xmllint/libxml2-utils issue johnraff was talking about, I think.

I thought I could be clever and fix it by installing libxml-xpath-perl and changing out the line to xpath, but nooo, that isn't going to cut it for me.

I also tried just installing libxml2-utils from unstable, but still received the "invalid output' error.

Last edited by sleekmason (2021-02-18 16:21:57)

Offline

#41 2021-02-18 18:49:30

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

sleekmason wrote:

I also tried just installing libxml2-utils from unstable, but still received the "invalid output' error.

ohnonot wrote:

If you run the script in a terminal it willmost likely tell you what's up.


Give to COVAX! Here or here. (explanation)

Offline

#42 2021-02-18 19:40:07

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

johnraff wrote:

@ohnonot you tested this on Arch? Problem with xmllint on Debian Buster is that libxml2-utils up to 2.9.9 outputs all the values on one line. I think 2.9.10 on Bullseye will add linebreaks so mapfile will work.

You're right.
That's madly inconsistent.
I was never 100% sure about xmllint, but since it's often already installed I used it.
But this - effit, let's use xmlstarlet instead.

Also, the icon theme paths are currently hardcoded in the script (anybody using this on their own system will need to adapt this; I'll likely make it more dynamic in the future though), and 'find' will barf when it doesn't find them, which in turn makes openbox fail with "invalid output".
I added a simple "2>/dev/null" to the 'find' command, which seems to fix it, although openbox only uses stdout output for pipemenus, not stderr. Weird.

Last edited by ohnonot (2021-07-04 09:24:22)


Give to COVAX! Here or here. (explanation)

Offline

#43 2021-02-18 20:19:05

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

ohnonot wrote:
johnraff wrote:

@ohnonot you tested this on Arch? Problem with xmllint on Debian Buster is that libxml2-utils up to 2.9.9 outputs all the values on one line. I think 2.9.10 on Bullseye will add linebreaks so mapfile will work.

You're right.
That's madly inconsistent.
I was never 100% sure about xmllint, but since it's often already installed I used it.
But this - effit, let's use xmlstarlet instead.

Also, the icon theme paths are currently hardcoded in the script (anybody using this on their own system will need to adapt this; I'll likely make it more dynamic in the future though), and 'find' will barf when it doesn't find them, which in turn makes openbox fail with "invalid output".
I added a simple "2>/dev/null" to the 'find' command, which seems to fix it, although openbox only uses stdout output for pipemenus, not stderr. Weird.

Anyhow, I added the script to my stuff repository now.

Installed xmlstarlet and pngquant - Getting:

/pipe-recent-files: line 54: type: file: not found

also added a line to the top of the icon list just in case:

"/usr/share/icons/gnome/${isize}x${isize}/mimetypes"

(hopefully this is correct ^ )

*edit - Also tried my direct line "/usr/share/icons/gnome/32x32/apps/accessories-text-editor.png\" removing the other lines just to check.

Last edited by sleekmason (2021-02-18 20:25:04)

Offline

#44 2021-02-19 03:21:00

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

sleekmason wrote:
/pipe-recent-files: line 54: type: file: not found

That means that the "file" program is not installed.
There's also a list of dependencies at the top of the script.
"apt install file".

also added a line to the top of the icon list just in case:

"/usr/share/icons/gnome/${isize}x${isize}/mimetypes"

(hopefully this is correct ^ )

This is correct.

*edit - Also tried my direct line "/usr/share/icons/gnome/32x32/apps/accessories-text-editor.png\" removing the other lines just to check.

for iconthemepath? That would be incorrect.

I will now add even more comments to the script, make sure you grab the newest version.

Last edited by ohnonot (2021-02-19 03:21:35)


Give to COVAX! Here or here. (explanation)

Offline

#45 2021-02-19 05:48:21

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

ohnonot wrote:
johnraff wrote:

libxml2-utils up to 2.9.9 outputs all the values on one line. I think 2.9.10 on Bullseye will add linebreaks

You're right.
That's madly inconsistent.
I was never 100% sure about xmllint, but since it's often already installed I used it.
But this - effit, let's use xmlstarlet instead.

xmllint seems to be on most systems by default, so in cases where it would do the job it would be a good choice.
From Debian Bullseye the linebreaks go in:
https://gitlab.gnome.org/GNOME/libxml2/ … c1c2cf1bce
As they say, it's a "breaking change" but the previous behaviour made the output almost unusable, so probably few people complained.

I ran 'time' on the three options 'xmllint', 'xpath' and 'xmlstarlet' and for some reason xpath was much slower than the other two, by a factor of 10. Xmlstarlet is very powerful and versatile - I'm  using it in a snippet I wrote years ago, but am now fired up to play with it some more...

---

recent wrote:

...get better mimetype (although this info is present in recentfile, but it's mostly garbage)

There is a possibility of improving the script here, though it would take quite a bit more work probably. Ignoring the mime-type entry in recently-used.xbel and just relying on xdg-open to open the file is quite a reasonable choice usually, but there are times when a file could usefully be opened by two quite different applications - think html files and browser vs text editor. In such cases it's useful to know what app the user actually last opened the file with, and that data is also in the xbel file.

My script (it wasn't written by Corenominal) parsed that out along with the file path, but I used an embedded awk section. (I was into awk at the time.) It would probably be quite possible to do with xmlstarlet + shell commands, but I don't feel like tackling it myself now: BL uses @twoion's lua script which works fine - as did my bash+awk script - except for the lack of icons. The icons are a definite plus though, for menus which are using icons elsewhere. cool


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#46 2021-02-19 14:03:48

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

johnraff wrote:
recent wrote:

...get better mimetype (although this info is present in recentfile, but it's mostly garbage)

There is a possibility of improving the script here, though it would take quite a bit more work probably. Ignoring the mime-type entry in recently-used.xbel and just relying on xdg-open to open the file is quite a reasonable choice usually, but there are times when a file could usefully be opened by two quite different applications - think html files and browser vs text editor. In such cases it's useful to know what app the user actually last opened the file with, and that data is also in the xbel file.

My script just uses xdg-open anyhow (another dependency I forgot to mention), and that's fine with me, but it wants to know the proper filetype to associate a meaningful icon (see screenshot).
recently-used.xbel seems to assign "application/octet-stream" to all executable scripts, which a) isn't very helpful and b) doesn't correspond to what my filemanager shows me (i.e. a shellscript icon) and c) there's no '*octet-stream*' icon on my system anywhere.
I even tried to figure out what process creates recently-used.xbel, maybe I could configure that instead... meanwhile 'file' will have to do - and because it can identify many files in one go, the overhead is minimal.


Give to COVAX! Here or here. (explanation)

Offline

#47 2021-02-19 21:28:22

sleekmason
zoom
Registered: 2018-05-22
Posts: 584

Re: [Solved] Icons in pipe menus

ohnonot wrote:
sleekmason wrote:
/pipe-recent-files: line 54: type: file: not found

That means that the "file" program is not installed.
There's also a list of dependencies at the top of the script.
"apt install file".

Yes, of course.  To make matters worse, I watched it uninstall not long before that while installing another program.  roll

Still receiving the Openbox error. 

Made sure xmlstarlet, coreutils, file, find, xdg-utils, pngquant, and graphicsmagick-imagemagick-compat (This was the package indicated for convert). <- Hopefully correct?

Installed the papirus icons as well for good measure just in case.

Now in a terminal I get:

sleekmason@ai:~$ pipe-recent-files
<openbox_pipe_menu>

Last edited by sleekmason (2021-02-19 21:30:03)

Offline

#48 2021-02-20 03:14:13

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 8,146
Website

Re: [Solved] Icons in pipe menus

ohnonot wrote:

My script just uses xdg-open anyhow...

As I said, a perfectly reasonable choice, I think. Its exact behaviour varies from system to system, though, because it hands over the job to some DE "*-open" type tool if it can find one. On BL it will call 'exo-open' because we set XDG_CURRENT_DESKTOP to 'xfce' (this could be up for reconsidering IMO).

...but it wants to know the proper filetype to associate a meaningful icon (see screenshot).

Does xdg-open assign an icon when opening a file? Or are you talking about the 'recents' script itself at this point?

...recently-used.xbel seems to assign "application/octet-stream" to all executable scripts

I just checked and saw 'application/x-shellscript' for an executable shell script, so this also seems to vary between systems. Maybe it's up to the application which last opened the file to add this entry?

I even tried to figure out what process creates recently-used.xbel...

Indeed. That would be interesting to know.

...'file' will have to do...

File seems quite usable. Another alternative is xdg-mime which comes with xdg-open though I haven't compared it.

---
But my point in the last post was about a possible alternative way of choosing an application to open the file - leaving the (impressive) icon mechanism you created in place. The xbel file records the last app to open each file (sometimes a list of two or three) in <bookmark:application... tags and the last two BL & CB scripts parsed out one of those to open the file. Sometimes that's what the user wants, rather than the preferred app derived from the mime-type + mimeapps.list (as with whether to open an html file in a browser or editor). It's not foolproof though. I've got a couple of dead entries in my current menu, which ought to be debugged...


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#49 2021-02-20 04:51:09

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

Oh, xdg-mime can also do this. Interesting, I'll have to check that out.
It's a shell script itself, so chances are good I can figure the mechanism out.

johnraff wrote:

I even tried to figure out what process creates recently-used.xbel...

Indeed. That would be interesting to know.

It's the application that first opens the file I guess.
Try clearing your recntly-used.xbel, then open an executable shell script straight from geany (not from the filemanager). Does it show up as "application/octet-stream" now?
I think there's something wrong with geany in that respect.

johnraff wrote:

But my point in the last post was about a possible alternative way of choosing an application to open the file - leaving the (impressive) icon mechanism you created in place. The xbel file records the last app to open each file (sometimes a list of two or three) in <bookmark:application... tags and the last two BL & CB scripts parsed out one of those to open the file. Sometimes that's what the user wants, rather than the preferred app derived from the mime-type + mimeapps.list (as with whether to open an html file in a browser or editor).

Yes, that makes sense, and I think I will amend that.

johnraff wrote:

It's not foolproof though. I've got a couple of dead entries in my current menu, which ought to be debugged...

My script drops non-readable (non-existing) files.

Also, other people have created openbox-recent pipemenus, I should research before re-inventing.


Give to COVAX! Here or here. (explanation)

Offline

#50 2021-02-20 04:58:03

ohnonot
...again
Registered: 2015-09-29
Posts: 5,520

Re: [Solved] Icons in pipe menus

sleekmason wrote:

graphicsmagick-imagemagick-compat (This was the package indicated for convert). <- Hopefully correct?

As long as convert works as required:

convert -background none someicon.svg someicon.png

---

Now in a terminal I get:

sleekmason@ai:~$ pipe-recent-files
<openbox_pipe_menu>

That's all? Weird.
Did you pull the newest version?
Do that, then if you still don't get more, try adding "set -x" to the top of the script.

Last edited by ohnonot (2021-02-20 05:01:30)


Give to COVAX! Here or here. (explanation)

Offline

Board footer

Powered by FluxBB