Show HN: Chext – a shell utility to change file extensions | Hacker News Reader

Show HN: Chext – a shell utility to change file extensions

github.com

5 pointsantognini19 comments

In zsh:

  autoload zmv
  zmv '(*).baz' '$1.bar'

How is it more convenient than `mv foo.bar foo.baz`?

Exactly what I was wondering.

Literally the only part that does anything is:

  mv $vflag $iflag $1 ${1%\.*}.$ext

Yeah, it doesn't do much. But every so often I find myself needing to change the extension of a bunch of files somewhere and needing to write something like "for f in $(ls *.txt); do ... " and then I have to remember how to strip out the prefix (do I use # or % or ##?), and then I have to try it out on a set of test files to make sure I'm not accidentally deleting them all.

I figured I would write something in the Unix philosophy to spare me (and maybe others) the trouble. It does exactly one thing, and it (hopefully) does it well. It was also fun to learn how to write a man page and do unit tests for a shell script.

you could just add it as a function to a .bash_profile

Very true! Maybe I'll make a gist with a function that can be copied into a .bash_profile.

Now try with more than one file like this:

    mv *.bar *.baz

This is one place where Windows CMD works:

    ren *.bar *.baz

It can't work on Unix shells because wildcard expansion is done before the program (mv) is invoked.

While not quite as convenient, it's not that tough in bash:

  ls *.bar | while read f; do mv $f ${f%.bar}.baz; done

also as

  for f in *.bar; do mv $f ${f%txt}baz; done

This is called brace expansion: http://wiki.bash-hackers.org/syntax/expansion/brace

Very useful stuff. E.g. mv nginx.conf{,.old}

Your version above has at least two bugs I see (will fall over with various forms of white space in the filenames). And it would be nice to have interactivity and verboseness (admittedly just flags to mv). It would also be better to work with plain portable shell, rather than requiring bash, so you'll need to include some basename calls. Also should it stop on the first rename failure, or just keep ploughing on no matter what?

Before you know it, you have a script you've debugged and tested.

The command I whipped up is, by definition, a one-liner meant for situations where the file movement is known by the person wishing to perform it and done interactively.

As to the portability of it, yes this is not portable as the syntax relies on substitution syntax supported by a limited number of Unix shells (bash and ksh spring to mind, others may support it too though).

Since the OP specifically mentioned:

  mv foo.bar foo.baz

And you pointed out CMD's 'ren' command, the incantation I put forth seemed apropos. YMMV.

Dealing with one file is no problem. A regular rename on the command line or gui file manager of choice works well. The difficulties come when trying to work with multiple files, and why you'd resort to the command line. Amusingly, the rename on Windows just works.

UNIX makes it difficult because of the wildcard expansion. You can start writing some script, but there are gotchas galore such as correct escaping, IFS, shell portability, dry runs, interactivity, error handling and the list goes on. Having something that works as well as the simple Windows command is hard work, and before you know it end up publishing a github repository!

  Dealing with one file is no problem. ...
  The difficulties come when trying to work with
  multiple files, and why you'd resort to the
  command line.

Maybe we just have a different perception regarding these workflows. Not that either is superior or anything, just different. My background is one where the command line is not something I turn to, but instead one where I begin.

  UNIX makes it difficult because of the wildcard expansion.

In this specific situation, your point is spot on. I submit that in many other situations, the wildcard expansion employed by many Unix shells is very helpful. Not every tool is applicable for every situation and the specific case of renaming multiple files to those with different extensions highlights a shortcoming of many Unix shells. Perhaps an explanation is due to file extensions being of little importance to the vast majority of Unix programs.

  Having something that works as well as the
  simple Windows command is hard work ...

Here, I will respectfully disagree and step away from this thread :-).

I've used a rename(1) utility^ that is apparently part of some Perl distribution. It's always been available on my Ubuntu systems and I haven't gone out of my way to install it. bar ⇒ baz would be something like: rename 's/\.bar$/.baz/' *.bar

You can dry-run first with `-n` flag if you're worried you didn't do it right, which is admittedly too possible. A bit more verbose, but a bit more powerful too.

^ http://manpages.ubuntu.com/manpages/trusty/man1/prename.1.ht...

I don't use Ubuntu, but it's weird that it seems to replace the rename command from util-linux, and has a completely different syntax:

http://manpages.ubuntu.com/manpages/trusty/man1/rename.ul.1....

Yeah, I found that as I was writing the comment. I guess the full names on Ubuntu are prename (P for Perl?) and rename.ul (UL for util-linux?) On my system, rename is symlinked to prename through the 'update-alternatives' system, but apparently rename.ul is not registered as a choice there. Strange.

Try `rename`

http://linux.die.net/man/1/rename

If on OSX:

    brew install rename

Reply on news.ycombinator.com