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

Feature Request: arbitrary suffix for -n #278

Open
sethmcg opened this issue Jan 29, 2024 · 0 comments
Open

Feature Request: arbitrary suffix for -n #278

sethmcg opened this issue Jan 29, 2024 · 0 comments

Comments

@sethmcg
Copy link

sethmcg commented Jan 29, 2024

Would it be possible to allow arbitrary suffixes to the -n flag, instead of just filetypes?

For me, the primary use-case for using the "-n" flag is to specify input files in a way that avoids clogging up the history attribute with dozens and dozens of lines of filenames, making it impossible to read through to see what happened and where something might have gone wrong.

However, sometimes (often, in the datasets I work with), the chunk of the filename that's incrementing numerically isn't at the end. For example, if I'm concatenating hourly files into daily files, they may be named something like temp_1980-03-21_HH:00:00.nc, where HH is the hour from 00 to 23. It would be really great to be able to use the -n flag to compactly generate the filenames.

I think this could be accomplished pretty simply by allowing one additional optional argument to the -n flag, an offset for the position of the numeric_suffix in the filename. For the example, you could then call ncrcat -n 24,2,1,,,16 temp_1980-03-21_00:00:00.nc to indicate that the width-2 numeric field (which goes by 1s from 00 to 23) has 16 characters ahead of it that should be used as the prefix, and everything after it is a suffix, including the filetype (which can be inferred in the normal way). If the offset is allowed to be negative, it could also be specified as -n 24,2,1,,,-9.

(I think it's more intuitive to specify how many characters to skip over, rather than the index of the start of the field itself, but whatever, either way I'd be happy.)

Thanks for considering it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants