Adding `path extension` command

[kaathewisegit]

Related problem

Updating extensions in Nushell is a bit cumbersome right now. Bash has their regex: ${f%.ext}.pdf, which is ugly, but short.

Describe the solution you'd like

A function to update extensions. Given that it can be implemented using existing path functions, I think it can go into the standard library.

# maybe a flag for not updating if a file has no extension
def "path extension" [ext: string] {
     path parse | update extension $ext | path join
}

Describe alternatives you've considered

No response

Additional context and details

Keeping it as an issue due to the parsing slowness (#13152). I'm not sure if it has been fixed or not

[dcarosone]

there is also path parse -e newext to slightly simplify your example, but it still needs to go back through path join (vs path basename -r which will replace in one step the entire basename part)

i think we're mostly favouring composition and simpler core commands with fewer options, which is fine as a goal but does tend to encourage verbosity.

Perhaps adding small functions like this to the std lib is the way to offset that; should we consider both the option forms in the above as candidates to remove and replace with wrappers over parse | update … | join?

[NotTheDr01ds]

@dcarosone I might be misunderstanding your path parse -e newext suggestion, but it doesn't appear that it works that way. It simply allows you to specify a more complex extension to find, not replace. Looking at the help path parse example, you still have to use upsert/update extension, then join it back again.

@kaathewisegit

It might be a bit "less-Nuish", but I'd probably go with:

"sample.json" | path parse | $"($in.stem).nuon"

That's far more concise, and yet still quite readable, I believe. I'm not sure we need a separate function for it, as simple as it is.

Regarding the performance issue, yes, #13152 has been fixed, and we can once again add to the standard library. It would need to go through std-rfc first. See the doc on that for more info.

However, there are a few reasons why I would suggest not putting it in standard library, though:

1. Mainly, the command-line alternative presented above is only a few characters longer than it would be if you invoked a path extension command:

   'sample.json' | path extension 'nuon'
   'sample.json' | path parse | $"($in.stem).nuon"

   Side-note: I think it should be named update extension anyway, so that's even less of a difference. A command named path extension would normally get an extension rather than change/update it.

2. You'd need a few more parameters to deal with things like the -e <complex_extension> scenario, along with updating the extension for a path rather than just a filename. path parse would strip the directory, of course, unless you had an option to add that back in. I think it's easier "as-is" than it would be with a custom command.

[dcarosone]

Yeah, sorry. it seems I am once again getting mixed up between basename -r and path parse -e; I keep thinking each works like the other for some reason.

[kaathewisegit]

@fdncred the problem with that approach is that it doesn't work for segmented paths as it drops directories. And Nushell template literals are a bit of a pain IMO, although that's a separate topic

I could in theory make my own module which loads utilities. The main reason I'd want to propose this for Nu std is because it allows to use this function in scripts, which can be distributed (i.e. with nupm). And I think that a separate command is the most readable solution. Updating an extension is the most common path-related thing I do in my local scripts