scrot
scrot copied to clipboard
scrot writes to a random-ass file name instead of the given one when it exists
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.
Ok, actually I use gnome-screenshot -a -f now (which also works without gnome), has this behaviour, and doesn't have the rectangle redrawing bug scrot has, so if no one else feels this way feel free to close this issue :)
I am observing a weirder behavior on my machine.
$ pacman -Ss scrot
community/scrot 1.2-1 [installed]
Simple command-line screenshot utility for X
The following creates two files
$ ls /tmp/*.png
"/tmp/*.png": No such file or directory (os error 2)
$ scrot "$(mktemp --tmpdir "${USER}-system.lock-screen.XXXXXXXX.png")"
$ ls -la /tmp/*.png
.rw------- 0 aureooms 14 Sep 11:29 /tmp/aureooms-system.lock-screen.Daefkf83.png
.rw-r--r-- 185k aureooms 14 Sep 11:29 /tmp/aureooms-system.lock-screen.Daefkf83_000.png
Whereas the following seems to work
$ cd ~/shots
$ ls -la
$ scrot '%Y-%m-%d-%H%M%S_$wx$h.png'
$ ls -la
.rw-r--r-- 166k aureooms 14 Sep 11:34 2019-09-14-113409_1440x900.png
Seems reproducible.
$ ls /tmp/.png "/tmp/.png": No such file or directory (os error 2) $ scrot "$(mktemp --tmpdir "${USER}-system.lock-screen.XXXXXXXX.png")" $ ls -la /tmp/*.png .rw------- 0 aureooms 14 Sep 11:29 /tmp/aureooms-system.lock-screen.Daefkf83.png .rw-r--r-- 185k aureooms 14 Sep 11:29 /tmp/aureooms-system.lock-screen.Daefkf83_000.png
Hi.
It is the behavior that is expected since mktemp creates the file and scrot sees that the file already exists.
The correct use would be mktemp --dry-run ...
Just spent some time scratching my head why my script kept uploading the same screenshot I took days ago. Looks like I was bitten by this anti-feature too.
Would you kindly not introduce breaking behavior like this, please? Thanks!
@daltomi Haha! Makes sense.
Not sure why nobody said this yet, but there -o, --overwrite flag to allow overwrite.
Ah, I see, it was merged later.
Our project was bitten by this change as well (robotframework/robotframework#3626). We cannot simply use --overwrite because we want to support also old scrot versions that don't have such option. Removing possibly existing file before using scrot is a simple workaround, though.
Because we can easily workaround this change, I don't care too strongly about this behavior. That said, overwriting the explicitly specified file sounds like a better design for me in general and doing this kind of backwards incompatible changes is especially questionable. Adding a separate option to avoid overwriting would have been safer.
Notice also that this overwrite avoiding feature doesn't work if the file uses .jpeg extension and in that case scrot fails to take the screenshot altogether. I'll submit a separate issue about that.
I generally agree that the current state, non-overwriting being the default, is not the best (I modified my build anyway, that was my workaround)
We cannot simply use
--overwritebecause we want to support also old scrot versions that don't have such option. Removing possibly existing file before using scrot is a simple workaround, though.
If this would get implemented in a new version - how would this benefit an older version?