Bash script called from global shortcut not works as expected

Help
, ,
1

Hello,

I’m facing an issue while creating a global keyboard shortcut.

My goal is to change display configuration (one shortcut to display only the TV screen, another to come back to my dual screen desktop configuration).

The first shortcut to switch on TV works fine with this command: kscreen-doctor output.HDMI-A-1.enable output.DP-1.disable output.DP-3.disable

The issue comes with the second script. I made a shell script to do more complex configuration. The script is:

#!/bin/bash

env > /home/seele/env-from-s.txt

kscreen-doctor output.DP-1.enable
kscreen-doctor output.DP-3.enable

kscreen-doctor output.DP-1.position.0,0
kscreen-doctor output.DP-3.position.2560,0

kscreen-doctor output.DP-1.priority.2
kscreen-doctor output.DP-3.priority.1

kscreen-doctor output.HDMI-A-1.disable

The script behaves weirdly when called using the shortcut, it works fine when called from the terminal.

So I added the line env > /home/seele/env-from-s.txt to compare with my session, and the file is never generated!

So I tried something else: I created a new shortcut with simply bash -c ‘env > /home/seele/env-from-s.txt’. And guess what? Nothing happens.

So right now I’m lost. I think this is a context issue (shortcuts may be launched from another context than the session, but that would be a strange design as the utility of such shortcuts is to behave exactly the same as if launched from the user).

Any clue? Thanks.

2

Out of curiosity I just tried this on Fedora KDE 43:

Created a ~/.local/bin/envglobal.fish file with:

#!/usr/bin/env fish

env > /home/myusername/env-from-s.txt

Added executable permissions to it with chmod +x, and added it to the global shortcuts. It runs fine here, even when I switch to bash.

I’d check to see if you actually have bash in your /bin or if you made the script executable.

3

I forgot to say I’m on Bazzite (based on Atomic Fedora, maybe that’s linked ?)

4

That is strange if the rest of the script is being executed.

Can you try other command than env, e.g. date or simple echo “$0” (print name of script)?

I am wondering if you are executing a different copy of the script

5

Sure, I tried this:

image
image1106×591 48.9 KB

I activated but no test.txt file found:

eele@DESKTOP-P144CQP:~/Documents$ ls -l /tmp/test*
ls: impossible d'accéder à '/tmp/test*': Aucun fichier ou dossier de ce nom
6

I wonder if you script is run a all?

You said it reacts weirdly so it sounds as if it does run but not do what it is supposed to do?
But then again not seeing your env output suggests that it does not run

7

The script initially does this:

  1. Enable desktop screen 1 and 2
  2. Disable TV screen

But when activated from the shortcut, it only enables one of the desktop screen. The other stays disabled. That’s the “weird behavior” I was talking about. At first I was calling the kscreen-doctor directly but then I tried with a script.

How can I be sure the shortcut is properly triggered? Is there any log or output in KDE? So far “dmesg” doesn’t show anything.

8

you can run your script in a terminal and observe echo output, or you can add kdialog messages for debugging so can ulitimately be able to follow along with the script as it executes.

9

I note the kdialog option thanks.

Meanwhile I removed the shortcuts and recreated it all, but using direct command kscreen-doctor instead of a script.

And what’s happing is unexpected.

The first command kscreen-doctor output.HDMI-A-1.enable output.DP-1.disable output.DP-3.disable perfectly works: both desktop screens off and the TV is on.

But when I try the second command kscreen-doctor output.HDMI-A-1.disable output.DP-1.enable output.DP-3.enable then TV is off, DP-1 is on but DP-3 stays off… unless I run the very same command from the terminal which output this:

Disabling output 3
Enabling output 1
Enabling output 2
qt.qpa.wayland: There are no outputs - creating placeholder screen

Hold on, I think we have a clue now, what’s this last message stands for?

10

the name probably change, because the screen config changed… you can’t assume the names are stable.

so you have to query, save to a variable, then call the action.

11

but that works perfetly fine when the command is called from a terminal, so I don’t think the names change. They are related to the connected port (DP for DisplayPort) so it would not logic for them to change.

12

so the 2nd command works from a terminal after you have already used the 1st command?

maybe this is at play