non-octal-permissions (RUF064)
Fix is sometimes available.
This rule is unstable and in preview. The --preview
flag is required for use.
What it does
Checks for standard library functions which take a numeric mode
argument
where a non-octal integer literal is passed.
Why is this bad?
Numeric modes are made up of one to four octal digits. Converting a non-octal integer to octal may not be the mode the author intended.
Example
Use instead:
Fix safety
There are two categories of fix, the first of which is where it looks like
the author intended to use an octal literal but the 0o
prefix is missing:
This class of fix changes runtime behaviour. In the first case, 400
corresponds to 0o620
(u=rw,g=w,o=
). As this mode is not deemed likely,
it is changed to 0o400
(u=r,go=
). Similarly, 644
corresponds to
0o1204
(u=ws,g=,o=r
) and is changed to 0o644
(u=rw,go=r
).
The second category is decimal literals which are recognised as likely valid but in decimal form:
256
corresponds to 0o400
(u=r,go=
) and 493
corresponds to 0o755
(u=rwx,go=rx
). Both of these fixes keep runtime behavior unchanged. If the
original code really intended to use 0o256
(u=w,g=rx,o=rw
) instead of
256
, this fix should not be accepted.
Fix availability
A fix is only available if the integer literal matches a set of common modes.