Ever since the creation of cds, I've struggled with creating a true wrapper function: one that completely emulates the behavior of the command it is wrapping (including error output) except when it can add some cool, additional functionality. In pr #56, I introduced some new code for cds that made it nearly perfect in this regard, making sure to preserve the error output of cd almost all the time, especially when we expect the additional functionality to fail.
There were two main drawbacks to that code, as I discussed in comment 26858406:
It's incredibly ugly and completely unreadable to someone unfamiliar with the intricacies of shell/unix.
It doesn't preserve the output of cd 100% of the time. Specifically, no error output would be shown if
1) cd doesn't work,
2) there exists a valid symlink with the specified shortcut name,
3) and (for whatever reason) that symlink doesn't work either.
The current pr addresses problem 2 by calling cd a third time to retrieve the lost error output if it is needed. This should not considerably impact the overall speed of cds because this happens pretty rarely.
It also tries to address problem 1 by including comments in the code and refactoring a portion of the code that was particularly terse (and used lots of fancy file descriptor redirections when it didn't need to). Thus, this pr resolves #73.
The pr also improves portability in cds -, which used a number of bashisms. This fix resolves #86.
Unfortunately, I'm still not perfectly satisfied with the code. If possible, I hope a future me will find a far more elegant solution to this whole problem of perfect wrapping. At the moment, I have serious doubt that shells are currently capable of an elegant solution, since I've been searching for one ever since I started cds and although I've learned a lot, it seems everything boils down to one big problem: you can't capture the output of a command in a variable without putting the command in a subshell (unless you use non-elegant stuff like temporary files, named pipes, non-POSIX stuff, or background processes). Until this changes, we'll be stuck with the current implementation of cds.
The new _cds
As of 8/23/19, this PR also now contains a small refactor of _cds, the function responsible for adding bash tab completions to cds.
Users of _cds should see only one major change: tab completions will now work correctly when a directory with the same name as one of your shortcuts appears in the current directory. This finally resolves #75.
The implementation of _cds has changed considerably, though. As of 59462a2, _cds is now no longer dependent on realpath. In my personal opinion, realpath offers many features of path resolution and canonicalization that are only really helpful in rare situations. Portable, simple alternatives to realpath exist when basic guarantees can be made about the path that is being resolved (for example: knowing that all directories in the path will exist). For these reasons, I removed realpath from the repository in da05455. That should resolve #33 and close #83. @GiselleSerate, you can revert da05455 if you still want to keep realpath.
aryarm
commented
5 years ago
The new
cdsEver since the creation of
cds, I've struggled with creating a true wrapper function: one that completely emulates the behavior of the command it is wrapping (including error output) except when it can add some cool, additional functionality. In pr #56, I introduced some new code forcdsthat made it nearly perfect in this regard, making sure to preserve the error output ofcdalmost all the time, especially when we expect the additional functionality to fail.There were two main drawbacks to that code, as I discussed in comment 26858406:
cd100% of the time. Specifically, no error output would be shown if 1)cddoesn't work, 2) there exists a valid symlink with the specified shortcut name, 3) and (for whatever reason) that symlink doesn't work either.The current pr addresses problem 2 by calling
cda third time to retrieve the lost error output if it is needed. This should not considerably impact the overall speed ofcdsbecause this happens pretty rarely. It also tries to address problem 1 by including comments in the code and refactoring a portion of the code that was particularly terse (and used lots of fancy file descriptor redirections when it didn't need to). Thus, this pr resolves #73. The pr also improves portability incds -, which used a number of bashisms. This fix resolves #86.Unfortunately, I'm still not perfectly satisfied with the code. If possible, I hope a future me will find a far more elegant solution to this whole problem of perfect wrapping. At the moment, I have serious doubt that shells are currently capable of an elegant solution, since I've been searching for one ever since I started
cdsand although I've learned a lot, it seems everything boils down to one big problem: you can't capture the output of a command in a variable without putting the command in a subshell (unless you use non-elegant stuff like temporary files, named pipes, non-POSIX stuff, or background processes). Until this changes, we'll be stuck with the current implementation ofcds.The new
_cdsAs of 8/23/19, this PR also now contains a small refactor of
_cds, the function responsible for adding bash tab completions tocds. Users of_cdsshould see only one major change: tab completions will now work correctly when a directory with the same name as one of your shortcuts appears in the current directory. This finally resolves #75. The implementation of_cdshas changed considerably, though. As of 59462a2,_cdsis now no longer dependent onrealpath. In my personal opinion,realpathoffers many features of path resolution and canonicalization that are only really helpful in rare situations. Portable, simple alternatives torealpathexist when basic guarantees can be made about the path that is being resolved (for example: knowing that all directories in the path will exist). For these reasons, I removedrealpathfrom the repository in da05455. That should resolve #33 and close #83. @GiselleSerate, you can revert da05455 if you still want to keeprealpath.