Since the following question came up, I have been meaning to go through all the /usr/bin files for jgmenu and change the invocations of geany to subl, the command for sublime text.
It’s been 8 months? And I am no closer to doing that than I was before. I’m old, time is fleeting, etc. And it has occurred to me that extensively customizing the jgmenu system would mean needing to keep an eye on updates and figure how best to merge any new features that I wanted–or just let the future of the menus unfold without me.
Thus: would you, keeper(s) of this awesome distro, consider adding support for text editors besides geany to the jgmenu system? It would make the menus themselves much more portable. Given all the work you have done on them, they could be worth sharing outside of Mabox. Fame and fortune await! Maybe.
Two ways to do this occur to me at the moment:
instead of having geany hard-coded as the text editor throughout the menus, scripts could check the mimetype of the file to be edited and open it in the default app for that mimetype.
add a mechanism for assigning a default text editor; scripts could then call for that default to open text files for editing.
There may be other, faster ways to do this, but if I were feeling very ambitious and wanted to implement this myself, I would probably start with one of these.
(And if it were a decade or so ago and/or time would slow back down to a reasonable rate of passage and/or the body would return to a reasonable rate of doing things, I would offer that ambition, time and energy for this. As it is, I will just thank you in advance for anything you do decide to do. Even if it’s just thinking about it and deciding not to do more than that.)
Sweet! Thank you for this. I have customized a few jgmenu-related things on my desktop, but I can check this out more quickly on my laptop later today. Will let you know how it works!
It works! That is, xdg-open does what it is supposed to do where you put it in the menu scripts: it opens text and other sublime-text-assigned mime types in sublime text.
Cool beans. Also, thanks.
It took me a bit to test this out as I decided to update the menu system on my desktop which meant moving a few customizations into mb-jgtools, including a submenu of tag^s that I figured out where to put the first time and then forgot why it was there and not somewhere else. In the middle of everything, my back decided it did not want to do its job anymore, so I have been in bed reading for the last few days.
There are worse things.
In any case, these menus are inspiring me to try learning bash scripting again. Like, from a book and examples on the internet. I may or may not find the energy to become proficient, but a little more practice can’t hurt. I can figure out what most scripts do, but bash is so terse, and confusingly like C but not always, that writing a working script from scratch is dicey.
But if I manage to produce anything interesting, I’ll be happy to share.
Yes bash is the most practical way to glue things together and is even fascinating to me–in the way an alien language might be fascinating.
&, for instance, sends tasks to the background. Sure, I’m good with that.
But… will it also act as a dereference for file descriptors? Are file descriptors C-style pointers? What is really happening with 2>&1 ? I have seen that construction sent to /dev/null/ in a couple of different ways, but I am still looking for a comprehensible description of why or how it works.
You don’t have to answer this either. I’m betting that Stephen Kochan’s book on bash scripting will tell me what I want to know, but I keep opening other books and reading about completely unrelated topics.
My back has stopped with the unusual pain and has returned to the minor nagging pains I am used to. Thanks for the good wishes!
STDIN (the standard input device, usually the keyboard but this can be changed) STDOUT (usually the screen, but again this can be changed, for example to send the output of a command to a file) STDERR (which receives the output from system errors, and by default sends them to the screen so that the user is aware of the error).
These are known as file descriptors, they describe where the output should go. These three are always open by default .
The expression 2&>1 simply means redirect file descriptor 2 (all errors) to file descriptor 1 (Usually the screen as stated above). The & is required to tell the system that we are redirecting to file descriptor 1 not a file named 1. The 1 is still pointing to the screen (STDOUT)
When we type 2&>1 we are telling the shell to send any errors (2 is STDERR) and the commands output (1 is STDOUT) to the same place. Sending this to /dev/null (the Bash black hole from which nothing escapes) simply means discard all output.
If we point a new file descriptor, say 4, to a new destination, here a file named myfile.
exec 4>myfile
Then if we now typed echo “Hello napcok!” >&4 then we would not see anything on screen as the output would go to the file myfile instead of the screen.
