Closed mtimkovich closed 3 years ago
I don't think I'm on board for this change. With this change, if I want to rename the folder src
to code
, that's sort of difficult to accomplish. Could sort of hack around this by adding a second argument, but that's an unexpected workaround.
I think it's better to just rely on the shell expansion for stuff like this, so if someone wants to rename all the files in the current directory or in the src
directory, they can do so like renamer *
or renamer src/*
, etc. Let me know if you think otherwise.
That makes sense. What do you think about only expanding . .. ~
? Right now it tries to rename a file called .
which of course doesn't work.
Edit: probably not ~
actually, that falls under shell expansion.
Yeah I'd be down for that, can't see what other behavior you'd expect when running with .
or ..
as the only argument. I kind of want to keep the semantics of mv
, but mv
doesn't allow you to rename .
and ..
, so feels okay to have some special case behavior there. The alternative could be to convert to absolute paths when renaming .
and ..
, so then mv
doesn't error out, but this behavior you've implemented seems more useful.
So yeah, I'm on board for .
and ..
expansion.
FYI @mtimkovich I'm about to merge some changes to the arg parsing, in #26 , just a heads up to pull to avoid conflicts, if you're working on the expansion of .
and ..
.
When the input is a single directory, list the contents of the directory instead. Mainly designed for the special directories like
.
,..
, and~
.