I have a program that tries to trigger a screenlock using the following commands:

    xdg-screensaver lock
    xscreensaver -lock
    cinnamon-screensaver-command --lock

The problem is that I'm using Arch and I'm not using any of the screenlock programs listed above. I need one of the above commands to trigger my swaylock script.

Is it possible to use a command with an argument to trigger a bash alias? For example:
alias xscreensaver -lock="cd ~/.config/hypr/scripts && ./lockscreen"

There are a lot of posts about using functions to pass arguments, but I haven't been able to find any info on how to use an argument in the command that triggers the alias. I'm guessing this isn't possible, but maybe someone has some alternative suggestions to get the same effect.

  • You can't do it with aliases... If you only expect this one argument to be passed, then you can use a function without even having to handle the argument Commented May 5 at 19:34
  • Like that: function xscreensaver() { cd ~/.config/hypr/scripts && ./lockscreen; } Commented May 5 at 19:36
  • Ok technically you can ignore the argument with an alias as well, like this: alias xscreensaver='cd ~/.config/hypr/scripts && ./lockscreen; :' Commented May 5 at 19:38

2 Answers 2


"Programs" (as in "not scripts") usually don't parse users' RC files. So if your "program" is not a script that can be easily modifiable, most likely, it will inspect PATH to find the path to those executables, or it will check for the presence of those executables in specific paths.

If your program reads PATH to find the path to those executables, one way to go about this would be:

  1. Creating a symlink to the script named as one of the executables, placing it into the same directory as the script's (or for that matter simply renaming the script as one of the executables)
  2. Modifying the way the program is invoked, to provide it with a custom environment with a PATH that includes /home/<your_username>/config/hypr/scripts
  3. No matter the options passed to the script, your script will just drop them and do whatever it wants.

As to how go about point #2 specifically: that depends on how your program is currently invoked. I can make this more specific depending on your case, but the general way to do this would be, instead of running program, running

env PATH="${PATH}:/home/<your_username>/config/hypr/scripts/" program

But this may or may not be applicable to your case, depending on how your program is invoked, and, again, depending on whether your program reads PATH to find the path to those executables.

This other way is rather a hack, and should be used only if the solution above isn't applicable, or if your program doesn't read PATH to find the path to those executables. See the caveat below.

Another way go about this, since you shouldn't have any of those executables installed on your system, would be:

  1. Picking one of the unused executables, let's say xdg-screensaver;
  2. Moving the script to the executable's path. On my system that would be /usr/bin/;
  3. Taking care of owner and permissions, mirroring the default permissions of the executables. On my system, those would be root:root / 0755;

The obvious caveat is: this is ok as long as some other program doesn't try to rely on xdg-screensaver for something. Essentially, this may break other stuff, cause suddenly an already installed program (or a program you'll install in the future for that matter) might find an xdg-screensaver executable available for use and run it. Since I guess your script isn't a full drop-in replacement for xdg-screensaver, this may break the program trying to use it.

So, again, this is rather a hack, and should be used with care.

  • The program is an appimage, so I'm not aware of a way to invoke it with the "env PATH" command. So I opted for your second suggestion and created a shortcut to my script in /usr/bin named cinnamon-screensaver-command, but the only problem is that the appimage invoked my script as root and wouldn't allow me to type in a password to unlock. Any suggestions?
    – guttermonk
    Commented May 6 at 2:51
  • @guttermonk Let me know if I understood correctly; your appimage runs as root, then, as root, invokes cinnamon-screensaver-command, which symlinks to the script in your home directory, correct? And since the script is invoked as root, you're then not allowed to unlock the screen once it's locked, correct? I'll provide you with a workaround, however I don't quite understand why you wouldn't run into the same problem when using the script on X11 and without the hack, the question is: why is the appimage running as root? Does it need to?
    – kos
    Commented May 6 at 4:52
  • @guttermonk If so, perhaps, the appimage is doing things differently to handle the call to those executables, something the script isn't receptive to. However: I'm plain unable to run xdg-screensaver as root (the executable just fails with status code 4) so, perhaps, the appimage will handle the call to xdg-screensaver in a different way then the way it handles the call to cinnamon-screensaver-command. So I would first try and "fake" the presence of xdg-screensaver in place of cinnamon-screensaver-command to see if that works out-of-the-box.
    – kos
    Commented May 6 at 4:52
  • @guttermonk Also, if that works, I think there's at least a way to use the env strategy instead of the dirty hack (by creating a desktop file and running that instead of the appimage directly)
    – kos
    Commented May 6 at 4:57
  • @guttermonk Finally, if you still get the same issue using xdg-screensaver, try and run the script from the terminal, and see if it actually works that way (although I'd wager you probably tried that already)
    – kos
    Commented May 6 at 5:00

First a remark: I find it better to give this function a new name, different from existing commands.

Now the function:

xscrsave (){
    case "$1" in
    (-lock) cd ~/.config/hypr/scripts 
    (*)     xscreensaver "$@"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .