Service Menus with Dolphin

[jlittle]

...will not launch:

Exec=zip.sh %U

... need to:

Exec=[B]sh[/B] zip.sh %U

Assuming the script is executable, and has the shebang, I would ask, where is the script? If it is sitting in the working directory specified in the .desktop file, as I expect given that sh zip.sh works, then there is a path ($PATH) issue. By default the current directory is not in the path. You can avoid the issue by invoking the script with "./" prepended, so, does this work?

Exec=./zip.sh %U

[Don B. Cilly]

And just to b. cilly, the #!/bin/bash shebang will use bash, sh will use



lrwxrwxrwx 1 root root 4 May 15 13:43 /bin/sh -> dash*

[wojcieche]

It should execute directly if
- It's set to +x (executable) and
- has #!/bin/bash at the beginning.

Assuming the script is executable, and has the shebang, I would ask, where is the script? If it is sitting in the working directory specified in the .desktop file, as I expect given that sh zip.sh works, then there is a path ($PATH) issue. By default the current directory is not in the path. You can avoid the issue by invoking the script with "./" prepended, so, does this work?

Exec=./zip.sh %U

Thanks guys! I had the script set to executable but was unaware of the shebang thing... ._. I added now and it works.
I am still a newbie in many Linux areas, learning on the way by trying out new things - like just right here, sorry... ;-)

I skipped the path to simplify the example, in fact I placed the script in a newly created directory in home and referenced to it using an absolute path, to make it reliable: ~/mybin/zip.sh
Maybe it is just me but I feel the mybin as a directory name to store custom scripts is unpretty and misleading (sounds a bit like my trash bin not my binaries - although in root there is bin, oh well). Is there a Linux established location/naming convention where to put such user scripts?

Also - how about the non-immediate refresh of context menu from .desktop files - looks like only I have this glitch? Maybe because of a different setup than yours - Arch + KDE Plasma + Dolphin...

[jlittle]

"bin" for binaries is ancient unix speak, getting on for 50 years now, if not more from a unix predecessor. /bin, /usr/bin, and /usr/local/bin will always be there.

But I agree that these archaisms can be confusing and unfriendly. Exploring more pleasant names is IMO a good idea.

[Don B. Cilly]

Well, if you
echo $PATH
~.local/bin should be there. Right?
And not have much in it, owned by you... not a bad place for scripts, is it?

About the refresh... just having to re-open Dolphin is not that bad...

[jlittle]

Well, if you
echo $PATH
~.local/bin should be there. Right?

(Assuming you meant ~/.local/bin). I thought, surely not, and I don't, but then I checked /etc/skel/.profile, and it has

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi

(The files in /etc/skel are copied when a new user is created.) I'd not seen this before.

The last time I looked at the default .profile it didn't have the .local bin, but that would have been a few years ago now. One is quite free to muck about with this, and I always have. Also, I use zsh now, and it doesn't source .profile at all.

[kubicle]

Also, I use zsh now, and it doesn't source .profile at all.

As a zsh user myself, I always symlink ~/.zprofile to ~/.profile just to get a more consistent experience/environment between shells.

As far as good places for locally generated user scripts, both ~/bin and ~/.local/bin will work fine (personally I find ./local/bin a bit "cleaner" as it buried in a hidden directory), but one is of course free to use whatever one wishes (but it helps if you add that to $PATH one way or another).

For system wide local scripts (meant for all users on the system), /usr/local/bin is the best place (you can also use /usr/local/sbin (generally for scripts meant for root only).

[Don B. Cilly]

Actually, I just realised that the "sudo touch" action doesn't work.
I had just tried it on "normal" files", not root-owned ones.
Then, I had the "Beached Dolphin" debacle, and left testing.
Until today, when Neon updated the kernel (an older one, again) and I had to "touch" the /boot entries.

If I right-click on a root-owned file , no actions are available.
If I use root-mode Dolphin, it doesn't find the actions (they're probably supposed to go in another place).

If I use root-mode Krusader, I set up the action within it , it works just fine. Which it would, I set it up in root mode...
Still, that's another point to Krusader. You just click Manage User Actions, use 'touch %aCurrent%' as a command, and Robert's you father's brother.
No need to edit abstruse .desktop files in far-away directories.

[chimak111]

How to change user and group ownership to root via service menu?

OS: Kubuntu 18.04

I have this service menu

[Desktop Action move-file]

Exec=/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu mv "%U" /usr/share/applications

Name=Move file

Icon=document-send

[Desktop Entry]
Actions=move-file

MimeType=application/x-desktop;

ServiceTypes=KonqPopupMenu/Plugin
Type=Service
X-KDE-Priority=TopLevel

The "Move file" option appears in Dolphin's right-click menu if the file being right-clicked is a .desktop file.

It pops up a window for me to enter my password and then moves the file to the destination folder.

However, the user and group are still mine, not root. How can I fix that in the Exec= line?

I can modify the Exec= line to copy the file's path like this:

Exec=printf %U | xsel -b -i && /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu mv "%U" ...

and that works to the extent that the file's path is in the clipboard (checked by using Ctrl+V in Kate) and the file is moved.

But then I'd also want something like

sudo chown root:root basename

to act on the clipboard contents in the destination folder. Is that possible and if so, how to do it correctly?

---

This works:

Exec=printf %U | xsel -b -i && /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu mv "%U" /usr/share/applications && cd /usr/share/applications && /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu chown root:root $( basename $(xsel -b -o) )

[jlittle]

Wouldn't it be easier to invoke a script in the Exec line, and get the script to do what's needed, with many advantages, like

• relaxed layout
• comments
• meaningful variable names
• opportunities for logging
• testing in isolation
• syntax highlighting while editing
• use of favourite scripting language

and so on?

[chimak111]

Wouldn't it be easier to invoke a script in the Exec line, and get the script to do what's needed, with many advantages, ...

No doubt about that but I have my limitations

Plus this issue came up as a question in another site. It's not something I plan on doing personally. The .desktop files I make or modify stay in ~/.local/share/applications.

[chimak111]

Service Menu to move selected files in a folder to a new subfolder

I came across this reddit thread: Dolphin: New folder with selected files ... how? and a response there points to this: https://aur.archlinux.org/packages/k...rwithselection

So I created $HOME/.local/share/kservices5/ServiceMenus/new_folder_with_selection.desktop with

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin,all/allfiles
MimeType=Application/octet-stream;inode/directory
Actions=NFFS

[Desktop Action NFFS]
Name=New Folder with Selection
Icon=folder-download
Exec=sh /$HOME/bin/new_folder_with_selection.sh %U

and
$HOME/bin/new_folder_with_selection.sh with

#!/bin/sh

dirname="$(kdialog \
 --inputbox "Folder to be created" "New Folder" \
 )" &&

mkdir -p -- "$dirname" &&

mv --target-directory="$dirname" -- "$@" ||

kdialog --error "Something went wrong"

[oshunluvr]

I want one to move files/folders up one folder - something I seem to do a lot. Seems easy enough, just haven't gotten around to it.

[kyonides]

Do you mean to move to a parent folder? Like in mv ../anything? Or like mv folder/new_folder?

[oshunluvr]

Yes, just up to the parent folder.

But it would be cool to have a "create folder and move" dialog. Sounds like a fun weekend project!