how to freeze the display screen?

[arivas_2005]

Greetings,
Another curiosity:
about using xdotool
How can I freeze the screen (not turn off) .. just freeze it to see.
just put it in disable and after the processes, re-enable

Thanks

[user1111]

Greetings,
Another curiosity:
about using xdotool
How can I freeze the screen (not turn off) .. just freeze it to see.
just put it in disable and after the processes, re-enable

Thanks

In a terminal you can freeze the display using ctrl-s and ctrl-q to release that.

In X you can turn off the screen and back on again using xrandr

However I don't know of any easy/standard way to freeze X screen updates. One idea that sprung to mind was perhaps to use xlock - something like ...

#!/bin/sh
xlock -mode image -geometry 0x0 &
PID=$!
.... do something
kill $PID

but screen updates during the locked state still show. There may be a way to extend that idea to have xlock display a captured snapshot image of the desktop, maybe adding something like ...

xwd -root -out screen.xbm
... and use that bitmap as xlock's displayed bitmap

... However if you're intending to do quick screen lock/changes/unlock then using xlock would tend to be too slow.

[MochiMoppel]

However I don't know of any easy/standard way to freeze X screen updates.

Maybe something like this:
1) Find PIDs for all windows of the current desktop. Don't know if xdotool can help, but it's possible without this tool.
2) kill -SIGSTOP all PIDs. This will freeze all windows (they appear to be dead, but they are not and will process all input once they are revived)
3) do some stuff
4) kill -SIGCONT all PIDs. This will revive all windows

Now the most important question: What's the point?

[arivas_2005]

Thanks MochiMoppel for your guidance
It's a great .. curiosity!
Is that I found how to freeze(disable) the mouse pointer with xinput, .. and also on keyboard (for a period) and then activate it again.
Then, the question appeared to me .. if you can freeze(disable) the mouse, the keyboard(disable) .. it is also possible to freeze the screen(put disable).. (I say while processes are being carried out and at the end .. they are activated (put enableds) again.)
I think that would be the point: the power to freeze depending on the case, the keyboard or the mouse, or ... the screen.
Thank you again..

[Flash]

Arivas, is your question answered, problem solved...?

[MochiMoppel]

@arivas_2005 OK, curiosity is a valid point

Taking up the idea of @rufwoof here is a script that will make a screenshot of your current screen and place it in front. Any keystroke will remove it and reveal again the live screen underneath.

Code: Select all

#!/bin/bash
IMAGE=/tmp/screen.png
ARRAY=($(xwininfo -root))
ffmpeg -t 1 -s ${ARRAY[27]}x${ARRAY[29]} -f x11grab -i :0.0  -y $IMAGE
echo '
<window decorated="false" margin="0">
	<pixmap tooltip-text="Press any key to close screenshot">
	<input file>'$IMAGE'</input>
	</pixmap>
<action signal="key-press-event">exit:</action>
</window>' | gtkdialog -cs
rm $IMAGE

[user1111]

However I don't know of any easy/standard way to freeze X screen updates.

Maybe something like this:
1) Find PIDs for all windows of the current desktop. Don't know if xdotool can help, but it's possible without this tool.
2) kill -SIGSTOP all PIDs. This will freeze all windows (they appear to be dead, but they are not and will process all input once they are revived)
3) do some stuff
4) kill -SIGCONT all PIDs. This will revive all windows

For me (Fatdog) the syntax seems to be ....

galculator &
... and note the PID

kill -s STOP <PID>

and to resume it

kill -s CONT <PID>

[MochiMoppel]

@rufwoof This would suggest that Fatdog is using busybox kill and not the bash builtin. Any reason for that?
Anyway, the bash builtin supports abbreviated signal names and of course the -s parameter, so your code should work on all systems.

[user1111]

@rufwoof This would suggest that Fatdog is using busybox kill and not the bash builtin. Any reason for that?
Anyway, the bash builtin supports abbreviated signal names and of course the -s parameter, so your code should work on all systems.

My Fatdog has /bin/kill - a actual binary, not a busybox symlink. kill --help shows the bash builtin kill help. /bin/kill --help shows the binary version help. busybox kill --help shows the busybox version of kill help text. i.e. the default kill is for the bash builtin version of kill.

[MochiMoppel]

kill --help shows the bash builtin kill help

Are you sure? The command for the builtin should be help kill

i.e. the default kill is for the bash builtin version of kill.

Your explanation suggests that Fatdog's shell doesn't even have a builtin kill command. If it would, the command kill --help would trigger an "invalid signal specification" error. Without a builtin kill --help and /bin/kill --help both call the binary.

[Grey]

kill --help or help kill

Interesting. In Fossapup, help for builtin kill is invoked by both commands, no difference between them.

[MochiMoppel]

kill --help or help kill

Interesting. In Fossapup, help for builtin kill is invoked by both commands, no difference between them.

I'm confused. What's going on here? I understand that it's possible to disable the builtin, which would result in the same output for kill --help and /bin/kill --help (both showing help for binary). In this case help kill would still show help for the (disabled) builtin. But why does kill --help show usage info for the builtin? What does the output look like and what is the command type reported by type kill ?

[Grey]

What does the output look like and what is the command type reported by type kill ?

type_kill.png (147.25 KiB) Viewed 982 times

and

type_kill_2.png (78.55 KiB) Viewed 981 times

[gruhyrose]

helpful for me, many thanks.

[MochiMoppel]

Now that this topic has been bumped so has been my confusion:
1) @rufwoof earlier commented "For me (Fatdog) the syntax seems to be ..", suggesting that my posted builtin syntax does not work.
2) @Grey 's first screenshot confirms that in Fatdog Fossapup kill is indeed a builtin, so my syntax should work for rufwoof.
The big question remains: Why does kill --help show the usage info for the builtin and not for the binary? Some kind of aliases at work?

[EDIT]Noticed that Grey was talking about Fossapup, not Fatdog

[wiak]

https://unix.stackexchange.com/question ... ed-in-bash

Highest priority is bash alias, then special builtins (only in POSIX mode), then functions, then builtins, then a search in $PATH.

Use:

Code: Select all

type -a kill

to see the precedence

manual for bash entry for 'type' gives the precedence.

Could use:

Code: Select all

$(type -P kill) --help

for non-builtin help

Command 'which' is an external program and knows nothing about shell 'alias' so reports PATH command.
(you could of course make an alternative bash 'alias' for 'which' rather than use external default which command ...)

In shell scripts I personally often use shell built-in command 'command' with the -v option (rather than 'which') to determine if a command exists and so do something-or-other accordingly (this is getting confusing...). For example:

Code: Select all

[ $(command -v pcmanfm 2>/dev/null) ] && FMANAGER="pcmanfm"

There is an advantage of using command -v in that it also detects existence of shell builtin (which 'which' alone would not).

[Grey]

The big question remains:

I thought you already forgot about this case. I already forgot about it And in essence... I don't know, it's just the reality. It works somehow. I was too lazy to find out. Maybe the author of Fossapup knows?

Didn't see right away that wiak had already answered above.

Let's go ... Something like this:

type-akill.png (81.75 KiB) Viewed 924 times

[MochiMoppel]

Didn't see right away that wiak had already answered above.
Let's go ... Something like this:

Well, it doesn't answer my question. Only confirms what was already evident from your confusing screenshots. However I noticed that you are using Fossapup, not Fatdog, which should give me the chance to check for myself. Let's see it something useful comes out of it.

[wiak]

The big question remains: Why does kill --help show the usage info for the builtin and not for the binary? Some kind of aliases at work?

My previous post answered this question, so I do not know what other question was not answered.

Note that whilst an alias takes precedence, there are ways to bypass such an alias, for example as discussed in following:

https://www.cyberciti.biz/faq/bash-bypa ... acos-unix/

[MochiMoppel]

My previous post answered this question

My "big" question was not about precedence. Maybe I should have kept it short ("Why does kill --help show the usage info for the builtin").

It now appears to me that newer bash versions support a --help option in addition to invoking usage info with the help command. Checked with Fossapup (bash 5.0.17) and Bionicpup (bash 4.4.19) and in both distros almost all builtins accept --help. So a user could use export --help or continue --help and would receive a short usage info. Interestingly the --help option itself is never listed in the usage info, which makes it an undocumented feature. Also the short option -h is not supported. In other recent distros like Slacko7 (bash 4.3.25) only the "classic" help command is supported and attempting to use --help would fail:

Code: Select all

# type -a kill
kill is a shell builtin
kill is /bin/kill
# kill --help
bash: kill: -help: invalid signal specification

[EDIT] Found the documentation. Feature was introduced in bash 4.4:

This is a terse description of the new features added to bash-4.4 since
the release of bash-4.3. As always, the manual page (doc/bash.1) is
the place to look for complete descriptions.

1. New Features in Bash

<snip>

h. All builtin commands recognize the `--help' option and print a usage
summary.

Well, not "all" builtin commands recognize it. Builtins like echo or true would not, but most builtins do.

[wiak]

@rufwoof This would suggest that Fatdog is using busybox kill and not the bash builtin. Any reason for that?

My "big" question was not about precedence.

The big question remains: Why does kill --help show the usage info for the builtin and not for the binary? Some kind of aliases at work?

My previous post answered this question, so I do not know what other question was not answered.

Then the big question seems to have been small, since kill --help as you have now accurately proved, reveals help, so glad you are now happy:

It now appears to me that newer bash versions support a --help option in addition to invoking usage info with the help command.

The answer to the 'big question' as asked above (re: why showed help for the builtin and not the binary), however, is 'precedence' per the answers now happily provided and understood. Moving on.

[Grey]

For myself, I made only one conclusion... I need to at least skim through the documentation after a major release of some commonly used program/utility. Mmm... Unless laziness wins