https://bugs.launchpad.net/ubuntu/+source/scrot/+bug/1698375

TODO:

• Configure autotools. Add lXfixes,lXcursor

• Add the option to activate the mouse capture. Maybe -p.

Right now I am not with my main computer.
TODO:

scrot -d 0.5 stopped working. It spits out: scrot: option --delay: '0.5' is not a number

I believe this is after I updated scrot through the package manager in Artix.

I git cloned and compiled scrot (tag:1.8.1). The problem is there. Then I tried the scrot obtained through sudo apt install scrot. That one works.

If you have nothing against restoring this functionality, please do it or say "do it" to me.

Hello,

Because I am using an older distro, only scrot 0.8 is available via apt repo. Therefor I was hoping to install from here to get the shiny updated version. :)

I downloaded release 1.7 but couldn't see what to do with it. Poking around in the directory there was only one other thing that looked as though it could be useful:

$ ./install-sh 
./install-sh: no input file specified.

I tried the readme instructions in case they were meant to be applied, but I do not think that's correct.

$ ./autogen.sh
zsh: no such file or directory: ./autogen.sh

and I tried skipping to the second step in case for some reason that would help

$ make install
make: *** No rule to make target 'install'.  Stop.

So I cloned the repo and attempted to follow the compile instructions from there. I solved one dependency in issue while ./configureing but then I couldn't solve the next one:

configure: error: BSD functions not found, libbsd is required

I searched in apt and found that there is a library called libbsd0 already installed. If it is equivalent then maybe it can't be seen due to slightly different name, which isn't something I know how to fix. I saw in the readme that maybe this can be circumvented, which got me to:

$ ./configure --without-libbsd
configure: error: BSD functions not found and --without-libbsd was used
make: *** No targets specified and no makefile found.  Stop.

This I can't interpret, but anyway I have no particular desire to compile anything if there is a simpler method available. If the release has an installer maybe it would be helpful to include specific instructions on how to access it.

Thank you for taking such good care of old projects.

When trying release the 1.2 version, I noticed the following lines:

gcc -DHAVE_CONFIG_H -I.  -g -O3 -Wall -I/usr/X11R6/include  -I/usr/include -I/usr/include -I. -DPREFIX=\""/usr"\" -I/usr/include/giblib -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/PKGS/scrot/scrot-1.2=. -fstack-protector-strong -Wformat -Werror=format-security -c -o note.o note.c
In file included from /usr/include/string.h:494,
                 from /usr/include/X11/Xos.h:62,
                 from scrot.h:36,
                 from main.c:33:
In function ‘strncat’,
    inlined from ‘im_printf’ at main.c:704:7:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:136:10: warning: ‘__builtin___strncat_chk’ output may be truncated copying 1 byte from a string of length 4095 [-Wstringop-truncation]
  136 |   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks!

Would it be possible to add an option for scrot to write the screenshot to standard output to avoid the image from reaching the filesystem?

I have seen scrot being used to capture screenshots for lock screens and since /tmp is not always in memory, these screenshots may reach the HDD and could be recovered later. This would be avoided by piping the image directly to the image processing (usually blur or pixelation).

I have tried process substitution in zsh (scrot >(image_processing_cmd)), but I only got giblib error: Saving to file /proc/self/fd/12_000 failed as a result.

I know it is possible to take screenshots of all of the windows using window compositor even though they are minimized or partially hidden, using the -k, --stack option.

Now is it possible to add a feature that does that opposite? It would take a normal screenshot (not joined) but hide a window/windows from the screenshot.

Thanks!

I use scrot -z -s '/home/user/%d%b-%H%M.png' -e 'xclip -selection clipboard -t image/png $f' to take a screenshot and put it to my clipboard, so that I can share it on emails and chats easily. This stopped working a day or two ago, and I'm not really sure why.

Distro: Arch Linux
Kernel: 5.16.1-arch1-1
Scrot version: 1.7

scrot first tries to select then does the delay, I think from user experience perspective, it should first wait and sleep for the delay and then allow user to select area for screenshot. In practice I often do sleep 5; scrot -s instead of scrot -d5 -s

I need the class name of scrot selection (mode=edge) to exclude it from picom.

This might be subjective, but I think most people use the left click when using the selection option. I think it would be a lot better if we just could hit the right mouse button and cancel the operation, instead of having to hit a key on the keyboard.

I know that I can simply do that myself, but I still feel like it's a pretty good option for everyone using this tool.

To reproduce:

$ scrot example.jpeg
$ scrot example.jpeg
giblib error: Saving to file example.jpeg_000 failed

Apparently the code to avoid overwriting the file introduced by #12/#15 doesn't work too well in this case. As discussed in #30, avoiding overwriting may not be the best default behavior in the first place.

Thanks for bringing this back. However, it depends on giblib which is still abandoned. Should this repo remove the dependency or should the org bring back giblib as well?

Add the option to format the name of the file with X11 window name

WM_CLASS(STRING) = "emacs", "Emacs"
For example, the screenshot of an emacs window will be "Screenshot_2021-12-07-11-11-11_Emacs.png"

I thought of using the output of xprop to format the file name. However, xprop doesn't read the WM_CLASS(STRING) on mouse hover.

Sometimes when I use scrot -s there's the white selection border visible on the screenshot. Sometimes it doesn't happen.
This is something I had way back when I was on Debian and I still have it nowadays on Gentoo.

Screenshot of the issue:

Bug from Debian[1]:

Trying to use scrot -m or --multidisp doesn't appear to work. Man page
says it should grab a shot from each display and then merge the image,
however it only appears to be taking a shot from one. Is there something
else that has to be configured/installed to allow this to work?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861907

On my system I don't have the libbsd installed:

checking for libbsd-overlay... no
configure: error: BSD functions not found, libbsd is required

I have seen that we have the --without-libbsd option, but it doesn't seem to work:
configure: error: BSD functions not found and --without-libbsd was used

Is it possible avoiding the use of libbsd?

Thank you in advance,
Emanuele

I'd like to run scrot from within a program, and the program is running
within a window which might be focussed (scrot -u :-)) but might not be :-(
I would really like a -w option to specify the WINDOWID
Would there be any chance of this happening ?

libXcomposite is only used for the function scrot_grab_stack_windows in main.c. It seems reasonable for this to be able to be compiled out. As I'm writing this, I realize the same argument could be made for libXext and libxfixes since they only affect scrot_grab_mouse_pointer. I feel like it is better for scrot to build and lose these two function than failing to build.

As a quick test, I just removed the body of the affected methods and updated the Makefile to not include the libraries and normal operations seem to work fine.

My 2 main grudges with it are that its interface is very clunky and that it's out of a screenshot program's scope.

The manual's example already shows some of that:

scrot -n "-f '/usr/share/fonts/TTF/DroidSans-Bold/40' -x 10 -y 20 -c 255,0,0,255 -t 'Hi'"

The entire argument to -n needs to be quoted so getopt_long() doesn't confuse it with one of its flags.
The user has to point scrot towards a font file instead of a font name because it doesn't use fontconfig to pick the font.
The syntax unnecessarily differs from other syntaxes used in scrot, such as the syntax of the -s flag or the -l flag. Really, all of those should just use the POSIX getsubopt() function instead.

I've actually needed an annotation feature in the past, but I used ImageMagick for it:

$ convert 2022-09-04-194335_956x536_scrot.png -pointsize 70 -fill Plum -stroke Gold -strokewidth 3 -gravity NorthEast -annotate +10+10 'test' out.png

ImageMagick's interface seems a little better, too, so I suggest removing annotations from scrot and leaving that to a different program. Would that be acceptable?

This is a general issue for tracking bugs I've found but not put in the work to fix before I forget them.

Currently unfixed

access()

The access() function suffers from a time of check to time of use issue. Nothing guarantees us that what access() could access will be there when we try to open(), or that what it couldn't access won't be there. The code shouldn't ask if it can do something, it should just do it and check the return value. This function shouldn't exist and its callers should be reviewed:

scrot --delay time drift

The implementation of the --delay option calls sleep() in a loop, time passes between each sleep() call, so it drifts.

Maximum filename length is wrong

Scrot uses this macro to check if input/output filenames are within a certain size:

The issue is that a maximum length of 256 is hardcoded, but the maximum filename length is a very complex issue. 256 could be too much or too little depending on the operating system, the file system, and even what directory the file is created in. The solution is that the code handling input/output filenames should pass around an alloc storage duration buffer and dynamically grow it as needed throughout the program's execution. Then, when the file is finally created, the system will return error if it fails to create the file.

Also, that code didn't have to be a macro.

Currently being worked on

alloc

It appears the return value of the allocation functions still isn't checked everywhere:

A more convoluted case:

It's very much possible for the allocation functions to return error, even on systems that overcommit like Linux and the BSDs:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main(void)
{
	void *p;
	if ((p = malloc((size_t)-1)) == NULL)
		puts("can't malloc SIZE_MAX");
	else
		puts("can malloc SIZE_MAX");
	pause(); /* Go inspect the virtual/physical memory usage. */
	free(p);
}

OpenBSD output:

In the real world, it's probably only going to happen on 32-bit, but don't worry about implementation details, just check the possible errors that the C allocation functions are documented to return.

Putatively fixed by #222 #242

Path of stdout

We don't need to know the path of stdout. It doesn't even necessarily have one. The code suffers from the same TOCTTOU mentioned above. It also uses /proc which is a Linux extension and the code is still present on non-Linux systems, so it's possible to affect the behavior of scrot by creating a /proc/self/fd/1 file on non-Linux systems.

This is probably because the imlib APIs we use want an output filename instead of an output file descriptor which is a design bug in imlib because it creates more races and unnecessarily limits the usefulness of the library. I looked at the headers of Imlib 1.10.0 and there is no function that writes an image to a given fd.

Imlib has added a function to address this in 1.11.0, we need to migrate to it.

These have been fixed

scrot --delay shortening

Sending SIGALRM to scrot while it waits causes sleep() to return early, and scrot then sleeps less than requested.

Fixed by #224

First time using scrot. I built it from master and tried it for the first time. I used the --select option.

Mouse changed to crosshair cursor. I clicked and dragged to define a region to capture. As I did, the bounding box left behind trails where it did not erase cleanly. These were captured in the screenshot that was saved, as well.

I tried building earlier versions (back to 0.9) and the bug exists in every version tried. It also exists in the distro version (1.2) installed with apt.

Linux Mint 20.1 MATE (Gnome2) w/ marco compositor, 4k monitors

I've seen this exact sort of bug before. It's usually caused by "erasing" a rectangle at a different size than was originally drawn.

Seems weird if I'm the only one seeing it, so I suspect some unusual graphics config is interacting poorly.

Thanks so much for maintaining scrot!

When downloading a release (e.g. https://github.com/resurrecting-open-source-projects/scrot/archive/1.3.tar.gz, the latest at the time of writing), the tarball does not contain a configure script, only a configure.ac.

While it is fine to require autoreconf during development, release tarballs are supposed to be created using make dist and contain an already-generated configure. This will make packaging easier for downstream distributions.

This is even more important now that you’re requiring autoconf-archive, which is not necessarily as widely available as autoconf/automake themselves.

Could you please use make dist for releases going forward? Thank you.

It would be awesome if scrot has an option to provide an image viewer (or you can pass xdg-open as a parameter for a more "portable" approach) to open the screenshot in.

I know the -e option exists and it can be used for that, but sometimes you might want to upload the screenshot and view it at the same time and that option would allow that.

I admit, that I haven't tried stacking -e options, so I don't know if that's possible, but either way, I feel like a dedicated open option, besides the execute option, would be the best solution.

Hi,

while evaluating this as an update for graphics/scrot in pkgsrc, I've got these warnings (on NetBSD 9.99.4 with clang + llvm 8). Fixes should be simple.

Making all in src
/usr/bin/make  all-am
clang -DHAVE_CONFIG_H -I.  -g -O3 -Wall -I/usr/X11R6/include   -I/usr/pkg/include -I/usr/pkg/include -I.  -DPREFIX=\""/usr/pkg"\" -I/usr/pkg/include -I/usr/pkg/include/giblib -I/usr/pkg/include  -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include  -O2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
mv -f .deps/main.Tpo .deps/main.Po
clang -DHAVE_CONFIG_H -I.  -g -O3 -Wall -I/usr/X11R6/include   -I/usr/pkg/include -I/usr/pkg/include -I.  -DPREFIX=\""/usr/pkg"\" -I/usr/pkg/include -I/usr/pkg/include/giblib -I/usr/pkg/include  -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include  -O2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include -MT getopt.o -MD -MP -MF .deps/getopt.Tpo -c -o getopt.o getopt.c
getopt.c:571:30: warning: implicitly declaring library function 'strcmp' with
      type 'int (const char *, const char *)' [-Wimplicit-function-declaration]
      if (optind != argc && !strcmp(argv[optind], "--"))
                             ^
getopt.c:571:30: note: include the header <string.h> or explicitly provide a
      declaration for 'strcmp'
getopt.c:649:15: warning: implicitly declaring library function 'strncmp' with
      type 'int (const char *, const char *, unsigned long)'
      [-Wimplicit-function-declaration]
         if (!strncmp(p->name, nextchar, nameend - nextchar))
              ^
getopt.c:649:15: note: include the header <string.h> or explicitly provide a
      declaration for 'strncmp'
getopt.c:652:32: warning: implicitly declaring library function 'strlen' with
      type 'unsigned long (const char *)' [-Wimplicit-function-declaration]
                (unsigned int) strlen(p->name))
                               ^
getopt.c:652:32: note: include the header <string.h> or explicitly provide a
      declaration for 'strlen'
getopt.c:701:19: warning: add explicit braces to avoid dangling else
      [-Wdangling-else]
                  else
                  ^
4 warnings generated.

Hi, I'd like to ask if the scrot project would be open to some changes focused on clean up, code quality and up to date practices. I'll get working on all them as soon as possible if I get a green light.

I apologize for the impromptu wall of text and possibly seeming rash, but I'm a fan of scrot and I can work on improving it in many ways. I'd like to know what the developers think of my ideas before commiting myself to them.

Immediately, I have a few ideas:

• Remove the strdup implementation in src/utils.c

It's a POSIX standard function implemented in all the big free unix systems (musl/glibc/dietlibc Linux, BSDs, Mac) and it might make it to the upcoming C2x standard
scrot depends on imlib2, which uses strdup as grep -Ri 'strdup' . in the imlib source tree will attest, and I can't find a place where it implements the function. scrot will be unable to use imlib2 before it's unable to use strdup.
strdup is the only function inside utils.c, so the entire source file and its header can go away.

• Remove the getopt_long implementation in src/getopt1.c and src/getopt.c

If the copyright is any indication, these source files were last updated in 1997 and the only changes since were local fixes for compiler warnings. They're written in pre-ANSI C, and the getopt_long function they implement is provided and actively maintained by all the major free unix systems.
getopt.c is 1047 lines, getopt.c is 187 lines, and getopt.h is 136 lines, which means this useless code is 43% of the scrot source.

• Add a modern build system, and (preferrable but not essential) remove the old one

I'm a fan of Meson, I will write and maintain Meson build definitions for this project.
The current build system has a few undesirable properties, both src/Makefile.am and Makefile.am hardcode include directories. src/Makefile.am also hardcodes optimization and debug flags (-g -O3).
configure.ac doesn't make use of pkg-config to find the libraries the project depends on.

Meson provides a lot of benefits.
It has integrated test support, so a test suite for scrot could be developed to catch bugs, and Meson also has integrated test coverage reports.
It integrates with IDEs (Visual Studio, XCode, you name it).
It exclusively builds in a build directory, so the source tree won't be cluttered with object files while working on the project. Meson also automatically triggers rebuilds when you change compile options, and it automatically detects header changes and triggers a rebuild of the affected source files.
Meson also abstracts away compiler details, so scrot would build unmodified with compilers other than Clang and GCC.
Meson automatically provides some things autotools does manually. Meson automatically figures out what to put inside distfiles, and you only need to rm -r the build directory to do the equivalent of a make clean.
Meson also has automatic build types, it defaults to debug so while programming the binary will be built with debug symbols and no optimizations. When a package maintainer packages a Meson package, producing a release build with optimization and no debugging symbols is as easy as passing a flag to the build system, same for adding more compiler flags.

• Make use of portable BSD extensions

Some C functions have caveats. strncpy for instance doesn't null terminate when the length of the source string is the same as the length of the destination buffer, leading to a buffer overflow when the string is used. When it does null terminate, it fills the unused space with zeroes pointlessly.
The BSD systems have an alternative called strlcpy (actually also present on MacOS and the musl libc for Linux) which does not suffer from these issues, and it can be provided by a compatibility library called libbsd. As you can see on the website, the library is widely available among Linux distros, and it isn't needed on BSD and MacOS because they implement the same functions in their libc.
A similar thing is true for strncat, there is an alternative provided by libbsd called strlcat.

Additionally, the library is full of useful functions, for instance the singly-linked list in src/slist.c could be provided by the library through this API, moving code out of scrot and into a library.

• Introduce CI

There is a service that provides free CI to FLOSS projects called Cirrus CI. With Cirrus, we can build and test scrot on many Linux distributions and also MacOS and FreeBSD automatically. I will admit I don't know very well how CI tests of an X application such as scrot would work, however.

• Rewrite the manual in mdoc

mdoc is the "new" format for man pages. It's supported by GNU groff (widely used to provide the man command among Linux distros), mandoc (provides the man command in a few Linux distributions and the BSDs), and even Vim's manual page reader. It can easily be written by a human, and it can also be converted to the classic unix "man" format.
It's better than man because its markup is semantic rather than visual. Because of this the manuals become more consistent and require less work to write, and a reader capable of reading mdoc can search for semantic elements of the manual. For instance, one can search for all manuals with a "-d" flag, or that contain a certain text string in the synopsis.

Bug from Debian[1]:

When using the $t special string in the filename, scrot segfaults and crashes.

$t represents the format of the saved image, which I believe is taken from the filename extension, so using $t in the filename should be prohibited. Still, the man pages does not specify this (as it does for other options, such as $f, $n and $s [full path, filename, size]). Most likely the documentation should be fixed but the program still shouldn't segfault.

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685173

Hi there,

I am using Amazon workspaces and I wanna launch an app on it that has scrot as a dependency.
The thing is, I can't figure out what is the right command to install it on Amazon Linux Distro.
Anybody can help me please?

TIA

I use to run this command to capture the screen, including a thumb:

scrot --thumb 100x0 /tmp/screen.png

The thumb used to have a width of 100 pixels, preserving the correct aspect ration. This broke with ff88b0b (I think, to be verified...) and returns an error message now:

scrot: option --thumb: resolution height '0' is too small

Can we define a special case for value 0 and have the old behavior back?

Is wayland supported?

Add Screenshot portal support so that it would also work on Wayland.

This truncates:

sizeof(buf) is 20:

POSIX says:

{HOST_NAME_MAX}
    Maximum length of a host name (not including the terminating null) as returned from the [gethostname()](https://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html) function.
    Minimum Acceptable Value: {_POSIX_HOST_NAME_MAX}

Further down:

{_POSIX_HOST_NAME_MAX}
    Maximum length of a host name (not including the terminating null) as returned from the [gethostname()](https://pubs.opengroup.org/onlinepubs/009695399/functions/gethostname.html) function.
    Value: 255

The fix here is to make buf's size HOST_NAME_MAX+1, but the real problem is the function's design. It should make gethostname() directly output to ret and it should dynamically grow ret as needed.

Hi all,

When preparing the 0.10 version, I can see that source code produces several warnings when building over Debian Sid.

I attached a log.

@daltomi Can you take a look over it?

Cheers,

Eriberto

build.zip

scrot -s allows to select an area to screenshot. Sometimes, it adds a white border to the screenshot (see attached picture), possibly it does not erase the selection rectangle before screenshoting. It happens especially on some electron apps.

Did anyone have success installing this in Fedora 34?

When ./configure is executed it returns two errors:

./configure: line 2525: syntax error near unexpected token 'src/scrot_config.h' ./configure: line 2525: 'AX_PREFIX_CONFIG_H(src/scrot_config.h)'

The solution is create the scrot_config.h with definition of SCROT_PACKAGE and SCROT_VERSION, but I believe this file should either exist in the repository or be auto generated by the build system.

look at the border of my bar. it's missing border at the right side because I am unable to select that area with scrot -s.

Currently, scrot has no programming style. The C source files have become a mixture of many different styles.

In src/slist.c:

• 2 space indents
• explicit cast of malloc return value
• function definition block starts in the same line as the function declaration
• no space between while and its parentheses

Meanwhile, in src/selection_edge.c:

• 4 space indents
• no explicit cast of calloc return value
• function definition block starts in its own line

And there's even a 3rd style in src/main.c which not all functions follow:

• 2 space indents
• function definition block starts in its own line
• function return value on its own line, separate from the function identifier
• no explicit cast of calloc return value

I suggest that scrot should have a single well defined style for all contributors to follow.
This style should have a few desired properties:

1. easy to enforce
2. easy to convert the existing codebase to
3. easy to remember

The style I'm thinking would be the best for scrot is the WebKit style.
This style is explained at length in the WebKit page, but it's very simple:

• 4 space indents
• function declarations and their linkages and return values in the same line
• goto labels at 0 indentation
• case jump labels in a switch statement have the same indentation level as the switch
• function definition's block starts in its own line
• pointers bind to the identifier, not the type
• conditional and loop blocks start on the same line as the conditional or the loop's parenthesized part
• there's always a space between a keyword and an open parentheses

I also suggest that the style should be made a little more strict, I have 2 rules to add which are not merely opinion based:

• no unneeded explicit casts
  Clang and GCC hide warnings when an explicit cast is made. Always using explicit casts will always hide warnings in the statement with the cast, and could hide bugs.
  A cast should only be made when necessary for this reason, the return values of malloc/calloc or the type of an assignment should never be cast.
• use the identifier and not the type in the sizeof operator
  If you use the type and not the identifier, you could one day change the identifier's type and accidentally leave the sizeof operator's argument untouched, leading to a bug. When the identifier is used as the argument, such a bug is impossible.

In practice, this style is extremely similar to K&R style, only its indentation is 4 spaces instead of an 8-column tab. The style is also almost the same as the "official" style used in the Golang programming language. It shouldn't be too foreign to a large quantity of C programmers.

The LLVM people have produced a tool called clang-format which automatically converts source code to a style, and this tool comes with the WebKit style by default.
Sadly, I have already confirmed clang-format is incomplete and can change the semantics of the source. This is unfortunately common with source formatters, I tried it and got a build failure. It also did not fully make the source compliant to the WebKit style, immediately I can see '*' characters aligning to the type rather than the identifier.

This change would have to be done by changing each individual file with the clang-format tool and fixing any bugs that crop up, then making a PR.

If this suggestion is accepted, our CONTRIBUTING.md will have to be updated, the list of files to be converted to the new style will be added to our TODO, and the style should be enforced for all new commits.

I guess since #12 / #15, scrot ignores the given file name and instead silently writes the result to a completely different file.

To reproduce:

$ scrot /tmp/screenshot.png
$ scrot /tmp/screenshot.png
$ ls /tmp/*.png
screenshot_001.png????

scrot should either fail with an exit code if the file already exists, or override the destination file by default like any other sane non-wimpy unix tool. Appending some random number to the file name may be useful if no output file name is explicitly given, but why would I even give it an explicit filename if it just ignores it sometimes? If you really want to have the behaviour that currently is the default, there should in my opinion be a flag like --no-clobber as is the standard (see e.g. man mv or man cp).

This change breaks by workflow.

This is a feature requested via bug[1] from a Debian user.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807139

The original Debian bug says:

Hello.

I have assigned the PrtScr key on my window manager
to the following bind:
scrot -q -z 'scrot_%Y%m%d_%H%M%S.png -e 'mv $f ~/Desktop'
which works absolutely fine.

However if there are more than one screenshots made
in the same second the file are being overwriten and
only the last one will remain.

There should be:

• an option to prevent/allow files to be overwritten
• if the option is set to not to overwrite files,
  a increment number could be appended to the file.

Regards,

Eriberto

Ability to select which monitor to take a screenshot of (the full monitor) on a multiple monitors setup.

I resized a spreadsheet window to larger than the width and height of my screen and tried to capture a screenshot with scrot -d 2 -u however only the portion that appears on my screen is in the image. How can I capture the full window, includnig the parts that are off the screen?

When you pass the -a option and coordinates, even when the -p option is provided and the mouse pointer is in the area, it is not captured.

since 95bea6b , we can't use -s as a short option (e.g., instead of -sf, we now have to type -s -f, because otherwise f is interpreted as an argument to -s.).

This has broken some scripts of mine on upgrading to Ubuntu 22.04 pre-release.

I believe that it is against standard command-line flag conventions to have -s take an argument despite being a short option.

These are some problems known in CWM at the time of using the area selection: scrot --select --line mode=edge
Note that scrot --select --freeze works well in them.

MATE desktop
It only draws a part of the rectangle, at the beginning. Notice that the CWM is by software.

xcompmgr
Draw the shadow. Beyond edge has the dock window property and is indicated to xcompmgr that does not draw shadows (-C) in that type of windows, it does it anyway.

Scrot version 1.5 introduced a small Control-Flow Integrity (CFI) violation. Specifically, the cfi-icall scheme was violated. I've fixed it in my fork of scrot on HardenedBSD's self-hosted GitLab: https://git.hardenedbsd.org/shawn.webb/scrot/-/commit/0f1728e323d5250936b00678c73abdc26d204546

I've also attached the patch to this issue.

scrot.patch.txt

This issue happens specially when the desktop is using tear-free updates (vsync)

Detailed explanation of how and why scrot leaves these visual traces to the composite communication layer explained here:

https://phab.enlightenment.org/T8552

Screenshot of the issue:

scrot uses the MIT-advertising license. It's a license created by the Enlightenment project which is the project that gave us imlib2, imlib2 is also under the same license.
The Fedora project considers it incompatible with the GPL because of its advertising clause.
If you CTRL-F "MIT-advertising" at spdx.org/licenses, you will see that the license is not certified Free/Libre by the FSF nor OSI approved. This is in all likelihood simply because nobody got around to doing it.

I think the lack of certification and the advertising clause are a significant annoyance, unenforceable (and why enforce it?), and that many contributors are unlikely to oppose changing to a license that provides the same terms except for removing the advertising clause.
Here's the advertising clause: acknowledgment shall be given in the documentation and software packages that this Software was used

We can only change the license of existing code with permission from the original authors, but we can require all new code to follow a new license. We can also ask the original authors to relicense their contributions.

I'd like to suggest requiring a new license for all new contributions called the ISC license. It's functionally identical to the MIT license, only its wording is more brief.
Here's a reproduction of it, formatted as an 80 columns per line C comment:

/* Copyright <YEAR> <OWNER>
 * 
 * Permission to use, copy, modify, and/or distribute this software for any 
 * purpose with or without fee is hereby granted, provided that the above 
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH 
 * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 
 * AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,
 * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM 
 * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR 
 * OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 
 * PERFORMANCE OF THIS SOFTWARE.
 */

Here are some other pages about the license:

• https://en.wikipedia.org/wiki/ISC_license
• https://www.gnu.org/licenses/license-list.html#ISC

If this is accepted, scrot will require this license for all new contributions, I'll relicense what I've contributed to ISC, and we can start asking contributors to do the same with their existing code.

A few days ago I used scrot to try to display differences of my tmux configs to my better looking half.
Just to see an old screencapture I did before, which I deleted already, was taken purely for test purposes.

Since then I could reproduce the bug somewhat consistent by just taking a few screenshots in a row.
Just used
for i in 1 2 3; do scrot; echo "$i"; sleep 1; done
and got a screenshot I did to test scrot after I reinstalled it an hour ago. (Which also is deleted for the same time).

Tested under i3 and bspwm, through different methods and naming the files and setting the overwrite flag.

(Also tested with st, termite, sxhkd and dmenu)

[Currently using Arch 5.5.6* and Xorg 1.20.7-1]