Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undocumented behavior in scrot #272

Open
guijan opened this issue Apr 9, 2023 · 0 comments
Open

undocumented behavior in scrot #272

guijan opened this issue Apr 9, 2023 · 0 comments
Labels
docs Documentation related

Comments

@guijan
Copy link
Contributor

guijan commented Apr 9, 2023

scrot has some undocumented behavior and sometimes deliberately continues with some kludge when it fails to comply with the user's request.

We can see here that if the user requests that the cursor be included in the screenshot and scrot fails to capture the cursor, it will go ahead anyway without the the cursor:

scrot/src/scrot.c

Lines 432 to 435 in 75664ef

if ((xcim = XFixesGetCursorImage(disp)) == NULL) {
warnx("Can't get the cursor from X");
goto end;
}

Here, scrot can't make sense of the user's wishes, but marches on anyway:

scrot/src/options.c

Lines 503 to 504 in 75664ef

for (; *argv; ++argv)
warnx("ignoring extraneous non-option argument: %s", *argv);

In imPrintf(), if the user asks us to include the thumbnail's filename in the command to execute but there is no thumbnail, we just ignore it:

scrot/src/scrot.c

Lines 624 to 627 in 75664ef

case 'm': /* t was already taken, so m as in mini */
if (filenameThumb)
streamStr(&ret, filenameThumb);
break;

We used to have an entirely undocumented feature: #216.

There are more instances in the code. We should start hard erroring if we fail to do what we were told to do by the user, and we should get rid of undocumented behaviors or adopt and document them if they're sensible like #216.

N-R-K added a commit to N-R-K/scrot that referenced this issue May 25, 2023
if the user asks us to grab the pointer, we should either do that
otherwise fail rather than continuing on.

also remove a redundant comment, it should be clear that a function
named XFixesGetCursorImage is indeed returning back a cursor image.

ref: resurrecting-open-source-projects#272
N-R-K added a commit that referenced this issue May 30, 2023
if the user asks us to grab the pointer, we should either do that
otherwise fail rather than continuing on.

also remove a redundant comment, it should be clear that a function
named XFixesGetCursorImage is indeed returning back a cursor image.

ref: #272
@N-R-K N-R-K added the docs Documentation related label Jun 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation related
Projects
None yet
Development

No branches or pull requests

2 participants