Describe the bug
When using e.g. files.line, edited files leaves behind backup files suffixed by =
To Reproduce
Use files.line, check filesystem for backup files
Expected behavior
Backup files cleary marked OR preferably removed if operation successful.
Meta
The replace command specifies -i="" for backup suffix, but the equal sign is interpreted as part of the suffix. MAN state for example that to backup files to end in .bak one should specify -i.bak.
https://github.com/Fizzadar/pyinfra/blob/9551a6f31cfaa0b582516f2e46d24c88a420d6d1/pyinfra/operations/util/files.py#L27
Would PR it, but not sure what the intended behavior is - do not use backup or use some more meaningful suffix (.bak or vi-style ~ would be fine by me)
Interesting! So looking at sed this is specific to the implementation of it (SUPER annoying!). Seems like BSD/MacOS/Alpine all follow as described, whereas other Linux distros only work with -i="".
Backup files cleary marked OR preferably removed if operation successful.
I think this is the solution - always specify a backup file and, if the user does not want it kept, remove it _after_ the successful operation. So will be both safer and enable users to keep backup files :)
Now implemented in https://github.com/Fizzadar/pyinfra/commit/8300bb41f1e1be7136ac9a411dfc4ff15c7bcca2 & released in 1.0.3!
The docs say:
Backup: If set to True, any editing of the file will place an old copy with the ISO date (taken from the machine running pyinfra) appended as the extension
I consider appending a file "editing", so I expected line + backup would
files.line(..., line=..., backup=True). However, no backup is made. Only when replace is included are there backups (sometimes). This seems to be a bug. I can't reproduce consistent backups.
@pylang you're absolutely right - I also think it should create a backup in this situation (of a blank file).
The above backup bug has been fixed by https://github.com/Fizzadar/pyinfra/commit/70cd8964d6f91ad3d7bab75d0448bb756adde45b.