Using Shortkeys in linux (my everyday List)

[bester69]

If you dont use shortkeys you dont use linux ..

- Ctrl+Shift + W ---> Open up, whatsapp Chrome

Code: Select all

#!/bin/bash
#
/opt/google/chrome/google-chrome --profile-directory=Default --app-id=bgkodfmeijboinjdegggmkbkjfiagaan &

- Ctrl+Shift + N --> Opens up Google Keep Notes

Code: Select all

#!/bin/bash
#
/opt/google/chrome/google-chrome --app-id=hmjkmjkepdijhoojdojkdfohbdgmmhki &
xdotool search --sync --onlyvisible --class "gcolor2" windowminimize &
sleep 1
gcolor2
sleep 1
WID=`xdotool search --name "Google Keep" | tail -n 1`
xdotool windowminimize $WID &
sleep 10
xdotool windowkill $WID &
sleep 2
ps aux|grep -i hmjkmjkepdijhoojdojkdfohbdgmmhk| awk {'print $2'} | xargs kill -9

- Ctrl+ Alt + C --> Opens up Google Chrome Calendar

Code: Select all

#!/bin/bash
#
/opt/google/chrome/google-chrome --app-id=magodclodecbbnbdfpmoehfdddkhlfmm &
 xdotool search --sync --onlyvisible --class "gcolor2" windowminimize &
 sleep 1
  gcolor2
 WID=`xdotool search --name "Clean Google Calendar" | tail -n 1`
 xdotool windowminimize $WID &
 WID=`xdotool search --name "Clean Google Calendar" | tail -n 1`
 xdotool windowkill $WID &
 sleep 2
ps aux|grep -i magodclodecbbnbdfpmoehfdddkhlfmm| awk {'print $2'} | xargs kill -9

- Ctrl+ Alt+ T --> Konsole
- Ctrl+ Shift+ D --> Dolphin Explorer
- Ctrl+ Shift+ K--> Kmail
- Ctrl+ Shift+ P--> PassX (password manager)
- Ctrl+ Shift+ R--> Recoll (Search indexing manager)
- Ctrl+ Shift+ Q--> QMplay2
- Ctrl+ Shift+ G--> smplayer
- Ctrl+ Alt+ G--> Gradio

Code: Select all

#!/bin/bash
#
radiopathback="$HOME/LINUXDEBS/config/de.haeckerfelix.gradio"
radiopath="$HOME/.var/app/de.haeckerfelix.gradio"
mkdir -p "$radiopathback"
if [ ! -z $1 ]
then
    killall gradio
    rsync -av --delete "$radiopath/" "$radiopathback/"
    exit
fi
flatpak run de.haeckerfelix.gradio &> /dev/null
sleep 2
rsync -av --delete "$radiopath/" "$radiopathback/"

- Ctrl+ Shift+ L--> lock desktop
- Ctrl+ Shift+ B --> Opens Cantata (mpd client music)
- Ctrl+ Shift+ 6 --> Play/pause toggle Cantata
- Ctrl+ Shift+ 7 --> Play Next track Cantata
- Ctrl+ Shift+ 5 --> Play Random track Cantata
- Ctrl+ Shift+ A --> Opens Cherrytree journal bbdd
- Ctrl+ Shift+ S --> Opera V7 Bookmarks (Extension)
- Ctrl+ Shift+ F --> Open CopyQ clipboard manager
- Ctrl+ Shift+ H --> Open Mate-system-monitor

- F12 --> Shutter Capture script
- Ctrl +Alt + F --> Faststone capture (wine)
- Ctrl + Mayus + X --> killall konsoles, okular, smplayer, nomacs
- Ctrl + Mayus + L --> LibreOffice

- Ctrl+ Shift + Left --> Window Active Snap left and 50% resize

Code: Select all

#!/bin/sh
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz &
WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,0,0,$HALF,-1
#Barra arriba WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,0,32,$HALF,-1
wmctrl -r :ACTIVE: -b add,maximized_vert

- Ctrl+ Shift + Right --> Window Active Snap right and 50% resize

Code: Select all

#!/bin/sh
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz &
#barra arriba WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,$HALF,32,$HALF,-1
WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,$HALF,0,$HALF,-1
wmctrl -r :ACTIVE: -b add,maximized_vert

- Ctrl+ Shift + Up --> Window Active Maximize

Code: Select all

#!/bin/sh
wmctrl -r :ACTIVE: -b add,maximized_vert,maximized_horz

- Ctrl+ Shift + Down --> Window Active restore

Code: Select all

#!/bin/sh
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz

- Ctrl+ Shift + ; --> Window Active Snap left and 75% resize

Code: Select all

#!/bin/sh
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz &
WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,0,0,$(($HALF*4/3)),-1
#Barra arriba WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,0,32,$(($HALF*4/3)),-1
wmctrl -r :ACTIVE: -b add,maximized_vert

- Ctrl+ Shift + : --> Window Active Snap right and 75% resize

Code: Select all

#!/bin/sh
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz &
WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,$(($HALF*2/3)),0,$(($HALF*4/3)),-1
#Barra arriba WIDTH=`xdpyinfo | grep 'dimensions:' | cut -f 2 -d ':' | cut -f 1 -d 'x'` && HALF=$(($WIDTH/2)) && wmctrl -r :ACTIVE: -b add,maximized_vert && wmctrl -r :ACTIVE: -e 0,$(($HALF*2/3)),32,$(($HALF*4/3)),-1
wmctrl -r :ACTIVE: -b add,maximized_vert

And, thats all for now, I know and use all of them by memory

[cuckooflew]

Wow, I am truely impressed, you must be proud of your self.
But ,

If you dont use shortkeys you dont use linux .

I don't use them my self, and I am using Debian, is Debian not Linux ?

[bester69]

.

[RU55EL]

If you dont use shortkeys you dont use linux ..

I would venture to say: If you don't use the command line, you don't effectively use Debian. Of course, there are short cut keys for the command line

I use the default shortcut keys. Which cover just about everything that I like to use. Granted, I can think of a couple that I wouldn't mind adding. But, I have never taken the time to create bash scripts to do so. I just set them up in GNOME settings, under devices: keyboard: shortcuts.

Edited to correct grammar.

[None1975]

If you dont use shortkeys you dont use linux ..

And I can paraphrase this phrase:

If you dont use tiling wm you dont use linux

[sunrat]

My boot manager says "Debian" and I use it but don't set custom shortcut keys. Does that mean Debian is not Linux any more?
It's an interesting exercise and satisfying to get little scripts like that to work. But say it took 2 hours to set up those keys and they save 3 seconds over using the menu or whatever, that's 7,200 seconds so you'd need to use them 7,200/3 or 2,400 times before you are ahead.

[Head_on_a_Stick]

Code: Select all

ps aux|grep -i hmjkmjkepdijhoojdojkdfohbdgmmhk| awk {'print $2'} | xargs kill -9

Shorter version:

Code: Select all

pkill hmjkmjkepdijhoojdojkdfohbdgmmhk

And none of your "scripts" need a bash shebang, !#/bin/sh is quite sufficient.

[bester69]

Code: Select all

ps aux|grep -i hmjkmjkepdijhoojdojkdfohbdgmmhk| awk {'print $2'} | xargs kill -9

Shorter version:

Code: Select all

pkill hmjkmjkepdijhoojdojkdfohbdgmmhk

And none of your "scripts" need a bash shebang, !#/bin/sh is quite sufficient.

heheh , at my 39yo im too old for changing myself

[pendrachken]

Code: Select all

ps aux|grep -i hmjkmjkepdijhoojdojkdfohbdgmmhk| awk {'print $2'} | xargs kill -9

Shorter version:

Code: Select all

pkill hmjkmjkepdijhoojdojkdfohbdgmmhk

And none of your "scripts" need a bash shebang, !#/bin/sh is quite sufficient.

No. NO. That is sloppy script writing. PERIOD. Never assume the shell you want is going to be executed, always specify the specific shell and environment you want. I don't care if you are only running one command, or if you are writing a complicated script with logic gates and tests. It's sloppy and a horrible habit to get into.

The way you want him to do it by linking /bin/sh is WRONG. "sh" can be linked to any shell, and won't necessarily follow bashisms properly. By linking to "sh" and writing in bash you are relying on the linked shell to both have bash compatibility, and be exactly analogous in behavior to bash. Most times it is true, but "most" only counts in proprietary consumer OS's and shitty software that is unsupported by the releasers. It is always best practices to specify the shell you are writing for, not assume that everyone is going to be using the same shell, or have /bin/sh linked to /bin/bash ( as it is linked to /bin/dash in Debian, and dash only MOSTLY supports bashisms ).

By calling /bin/bash explicitly you are going to get either one of two outcomes consistently - 1: your script executes the same way every time, on all machines, no matter what the default shell is or 2: you get an error about not having bash installed.

[Head_on_a_Stick]

"sh" can be linked to any shell, and won't necessarily follow bashisms properly.

Perhaps try reading the OP's "scripts"? None of them use bashisms...

And /bin/sh is strictly defined by the POSIX specification so using that shebang and following the specification will result in truly portable utilities.

[pendrachken]

Yes, actually I have. It's still bad practices to assume, even if it will work 99% of the time.

There is at least one script there that will not execute if the user defaults to linking /bin/sh to CSH. The if:then statements are different, and the test is written differently, with different braces.

The likelihood of that isn't ZERO, so it is bad practices. Even relying on zsh's bash compatibility isn't something I would recommend, unless you want to trace down obscure bugs that can be introduced.

[Head_on_a_Stick]

There is at least one script there that will not execute if the user defaults to linking /bin/sh to CSH. The if:then statements are different, and the test is written differently, with different braces.

Only an idiot would symlink /bin/sh to csh, it's not even a Bourne shell. See also http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

As I explained above /bin/sh has a very clear specification and so will always operate in the same way. This is in contrast to bash, the behaviour of which changes from one release to the next — for example, if a bash script is written using bashisms from version 5 then it might not work at all on Mac OS X, which runs version 3.

And if you think using a /bin/sh shebang is such a bad idea then why do all of Debian's system scripts use it?

[pendrachken]

1: I don't care what shell anyone links /bin/sh to. There are people out there that do strange crap, and break things in strange ways. Especially embedded devs. It's not impossible, as I've said, even if it is unlikely.

And if you think using a /bin/sh shebang is such a bad idea then why do all of Debian's system scripts use it?

Nice appeal to authority fallacy you got there.

But the obvious answer is because they aren't following best practices, even if they are specifically writing for their own platform.

[Head_on_a_Stick]

because they aren't following best practices

Best practice would be to avoid bash like the plague — it's a buggy, bloated mess of a shell.

But anyway I'm sure you know better than those silly Debian developers...

[LE_746F6D617A7A69]

As I explained above /bin/sh has a very clear specification and so will always operate in the same way. This is in contrast to bash, the behaviour of which changes from one release to the next — for example, if a bash script is written using bashisms from version 5 then it might not work at all on Mac OS X, which runs version 3.

I disagree - ksh and many other shells are mostly dead projects (f.e. the last commit in ksh was in 2012, and it's not actively developed since that time), so the set of functionalities, features and bugs is the same for every platform that uses it - this has nothing to do with "clear specification"

Bash on the other hand is actively developed (last commit was on 2020.04.24) - and it is obvious that new features will not be supported on older versions - so, just like in case of python or gcc, every OS which is actively maintained should use the latest official stable versions.
I don't know what version of Bash is available on OSX - if it's really v3.x, then it means that OSX simply doesn't officially support this shell.

If "bashisms" means using bash-specific features, then we have also "dashisms" and "kashisms" for ksh - all those shells have specific features or parameters which are breaking portability of scripts.

Best practice would be to avoid bash like the plague — it's a buggy, bloated mess of a shell.

Again, I disagree with Your claim - I'm using Bash for running quite complex scripts, and I haven't found any bugs - if You can prove Your claim, You should file a bug report.

But the obvious answer is because they aren't following best practices, even if they are specifically writing for their own platform.

"Best practices" means different things, depending on who's using that term.

Regards

[Head_on_a_Stick]

ksh and many other shells are mostly dead projects (f.e. the last commit in ksh was in 2012, and it's not actively developed since that time)

Erm, no. The original ksh93 was revived by AT&T a few years ago and Debian now package the new "2020" version in sid: https://packages.debian.org/sid/ksh

There is also the MirBSD KornShell, which is the stock shell for Android and so has more users than bash: http://www.mirbsd.org/mksh.htm ← last commit 20 days ago.

And don't forget OpenBSD's ksh(1)

this has nothing to do with "clear specification"

No, KornShell has nothing to do with the POSIX sh specification, which is what I was talking about...

If "bashisms" means using bash-specific features, then we have also "dashism" and "kashism" for ksh - all those shells have specific features or parameters which are breaking portability of scripts.

Yes and that's exactly my point — if the POSIX sh specification is followed and a /bin/sh shebang employed then scripts will be portable between distributions and operating systems.

I'm using Bash for running quite complex scripts, and I haven't found any bugs - if You can prove Your claim, You should file a bug report.

No need for that, Debian already has over 200 active bug reports: https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable

And even the man page admits to it's failings:

BUGS

It's too big and too slow.

[LE_746F6D617A7A69]

ksh and many other shells are mostly dead projects (f.e. the last commit in ksh was in 2012, and it's not actively developed since that time)

Erm, no. The original ksh93 was revived by AT&T a few years ago and Debian now package the new "2020" version in sid: https://packages.debian.or/sid/ksh

There is also the MirBSD KornShell, which is the stock shell for Android and so has more users than bash: http://www.mirbsd.org/mksh.htm ← last commit 20 days ago.

Debian has both pdksh (aka ksh93) and mksh (MirBSD Korn Shell), and You're right: mksh is still developed, (EDIT: but pdksh is dead)
EDIT2: I've downloaded the sources for ksh 2020 version, and in the changelog there's a list of "Notable non-backward compatible changes" - that list is quite long... /EDIT

It's not clear for Me, what do You mean by saying that mksh has more users - is it because there are more Android-based devices than Debian-based - or what?

(...) if the POSIX sh specification is followed and a /bin/sh shebang employed then scripts will be portable between distributions and operating systems.

Not really - in most cases scripts are used to automate OS-specific tasks. Even if You will use 100% POSIX compatible shell, the scripts are still non-portable.

Example: here I'm using a trivial shell script, which is switching performance modes on my GFX card - this script is 100% POSIX-compatible, and 100% non-portable to other OS-es -> it requires specific kernel, gfx driver and a helper application.

So, for scripts that are OS-specific it makes no sense to use POSIX standard - such scripts should be written for default OS shell (using its specific features if needed)

And even the man page admits to it's failings:

BUGS

It's too big and too slow.

Yeah, I know that...

[Head_on_a_Stick]

Debian has both pdksh (aka ksh93) and mksh (MirBSD Korn Shell), and You're right: mksh is still developed, (EDIT: but pdksh is dead)

ksh93 is not derived in any way from pdksh, it was originally a proprietary product and pdksh was developed independently because of this. Both mksh and OpenBSD's ksh(1) are derived from pdksh and can be considered the active successors.

I've downloaded the sources for ksh 2020 version, and in the changelog there's a list of "Notable non-backward compatible changes"

Kurtis Radar stripped out a lot of David Korn's original code and also moved from AT&T's own build system to Meson. The ksh93 community were appalled by this and eventually persuaded AT&T to transfer krader's version to a separate branch and re-instate the 2012 version of ksh93 to the master. Juicy details here and here. The community is now trying to develop ksh93 themselves here. Debian now also provide a specific ksh93 package in sid: https://packages.debian.org/sid/ksh93 (see https://bugs.debian.org/cgi-bin/bugrepo ... =%23948745 for the details).

It's not clear for Me, what do You mean by saying that mksh has more users - is it because there are more Android-based devices than Debian-based - or what?

Yes, there are more Android devices than Debian machines.

Anyway, I think we've hi-jacked the OP's thread quite enough by now. Please open a new thread if you want to continue this discussion.

[LE_746F6D617A7A69]

Anyway, I think we've hi-jacked the OP's thread quite enough by now.

Yes, I agree.
---------------------------------------------------------------------------------------------------
So, let's get back to the topic:

I would venture to say: If you don't use the command line, you don't effectively use Debian. Of course, there are short cut keys for the command line

I use the default shortcut keys. Which cover just about everything that I like to use. Granted, I can think of a couple that I wouldn't mind adding. But, I have never taken the time to create bash scripts to do so. I just set them up in GNOME settings, under devices: keyboard: shortcuts.

Same here, but I use XFCE exclusively.

One remark: the howto from your link is a little bit incomplete, because there are also other very convenient shortcuts available for the terminal, f.e:
Arrow<Up/Down> : an alias for Ctrl-<P/N>, view previous/next command from the history
Alt+Backspace : delete word to the left, just like Ctrl-W
Ctrl-G : cancel searching historical commands, used with Ctrl-R (very useful in some cases)
and the most "powerful" pair:
Shift-Ctrl-V : paste text into the terminal at current cursor position
Shift-Ctrl-C : copy selected text from the terminal window

Besides that, I'm using 2 non-default shortcuts:
Ctrl-Alt-T: launch the terminal under mouse pointer
Ctrl-Alt-Shift-Arrow<Left/Right/Up/Down> - move active window to a neighbouring workspace (Ctrl-Alt-Arrow<Left/Right/Up/Down> is just switching the workspaces)

Regards.