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

Prompt existing overwrites when using lnav -i <file> #1240

Closed
lamchau opened this issue Mar 4, 2024 · 1 comment
Closed

Prompt existing overwrites when using lnav -i <file> #1240

lamchau opened this issue Mar 4, 2024 · 1 comment
Labels
enhancement Feature Request

Comments

@lamchau
Copy link

lamchau commented Mar 4, 2024

Is your feature request related to a problem? Please describe.
Running lnav -i <file> to install log definitions will clobber an existing ones. Generally this is preferred but when sharing definitions to other users (in a team setting) who edit the "base format" to add their own customizations may inadvertently lose them.

Context: This is usually user error but adding a small quality of life improvement to prevent destructive format installs would be a nice addition. A contrived but plausible scenario is running lnav -i $XDG_CONFIG_HOME/lnav/formats/installed foo.json will yield a 0 length file.

Describe the solution you'd like
Prompt the user that an format definition already exists and give them a chance to bail/overwrite. It should print out the absolute path so it's fast to backup/edit.

Note: I'm not sure how this would adversely impact lnav -i extras since that might be expected (as an update). But that's extra work that's probably not needed.

Describe alternatives you've considered
Workaround using a bootstrapping script

lnav_format="$(lnav -m format my_json_log source 2> /dev/null)"
if [ -n "$lnav_format" ]; then
  confirm="n"
  echo "warning: my_json_log format already exists '$lnav_format'"
  read -r -p "overwrite? [y/n] " confirm
  if [[ "$confirm" =~ [NnQq] ]]; then
    exit 0
  fi
fi
@lamchau lamchau added the enhancement Feature Request label Mar 4, 2024
tstack added a commit that referenced this issue Mar 7, 2024
@tstack
Copy link
Owner

tstack commented Mar 7, 2024

Good catch, thanks for raising the issue. I pushed a change that adds some more checks to the installation path:

  • Writing the file is proper now, it writes to a temp file and then renames it over the destination path;
  • If the source and destination are the same, nothing is done;
  • If there is a destination, and it's different, the old files is renamed with '.bak' at the end and a note is included in the success message

@tstack tstack closed this as completed Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature Request
Projects
None yet
Development

No branches or pull requests

2 participants