-
Notifications
You must be signed in to change notification settings - Fork 13
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
Bless @rrthomas' fork? #7
Comments
Hi @kcoyner, I wrote to you in July 2018 about maintaining rpl, which I have been doing since then; Debian switched to my upstream shortly afterwards. |
A new year has begun and I've returned to rpl to update the copyright lines in my projects :) @rrthomas, great to see you continuing with the project! Didn't know that Debian switched to your fork (I just followed the "homepage" link of Debian Buster's version of rpl, which still points to this repository). I'm happy that I could help with my changes :) Since I'm interested in rpl being maintained, I support the suggestion of making @rrthomas's fork somehow official, especially if that is the only practical option there is for the time being. In any case, thanks to you @kcoyner for your work as well! |
Just to say, I'd be quite happy to become the "official" maintainer, whatever that means! I use rpl regularly, and have been helping packagers adopt my version. I don't have any major plans for changes/new features (which at this point will probably be a feature, not a bug, to most users!). |
RPL is find and replace. @rrthomas You removed the -R flag from find and replace. Which is primary usage of RPL in software development. Your justification for removing the -R flag was that it was "dangerous". Maybe you should become the maintainer of "rm" and remove "rm -R" because its "dangerous"? Your change to rpl, broke a unix/linux command that has been used and taught in schools and tutorials the same way for 40 years. @encukou The bug tracker is full of issues because of rpl -R option was removed. This is a huge headache because xargs have problems with filenames with special characters and spaces in it. |
@SkycoinSynth, since version 1.8, you can use recursive glob patterns to do recursive replacement safely. I'm happy to look at issues. The I've explained the use of |
One of these two commands, is cleaner, simpler and more readable than the other.
There is no possible justification for forcing people to use xargs, over a simple one letter command line argument, except out of malicious intent. If you were the the maintainer of grep and rm, would you take it upon yourself to remove the -R flag, to force people to use xargs? |
As documented in the man page: |
BTW. Today, I had a script that ran for a decade and which has not been edited for eight years. And that script worked perfectly on BSD and on OSX and on my development machine. But the script failed on a docker deployment using a newer Debian image, because of your removal of this simple and essential command line argument. In fact only ten lines of code. And the xargs solution is much less reliable because it requires special care and extreme skill to deal with filenames with white spaces and escaped characters. In general, I support maintaining comparability between linux distributions. And I support maintaining agreement of utilities with their documentation and the linux man pages. |
If you find that |
grep -n "a" '**' I would in general, maintain the same standard command line arguments as supposed by find, grep, rm and other linux tools. Instead of inventing new conventions. And I appreciate your glob improvement and unicode support is better now, but its unnecessary and undesirable to remove standard command line arguments. |
An internet troll has asked me "ask him to provide you the correct xargs command for filenames that may have spaces or newlines in them". Can you answer his challenge? |
It's not a new convention, recursive globbing has been in shells (and Python's standard library) for decades. |
As I have said, |
Just because globbing is a valid method, does not mean that we should handicap people by forcing them to glob. Should we force people to glob when using grep? Should we remove the -R flag from grep? This is a corporate issue. Maintainability issue. Standards issue. No one in the linux community supports the removal of the -R flag. No one benefits from it. Everyone suffers. This is a very bad attitude for a maintainer, over ten lines of code in a commonly used command line utility. I dont know if you understand how many bugs or tickets were entered over this issue already. |
@SkycoinSynth I think I've already addressed all your points; sorry, I don't have more time for this now. |
You made false claims. You claimed that your example of shell commands, that replace rpl -R can be used in the same circumstances and when tested, the commands you provided (there were three of them) do no all handle unicode file names, file names with spaces and file names with new line characters in them, in the correct way. I do not believe you have given sufficient justification for neutering the rpl command and your justifications show that you are not suitable as a maintainer for Debian. |
Here are the three commands I gave in rrthomas#9 (comment) :
Note, I said about the first: "this will work for all filenames that don't contain a newline." Here's a shell session:
In other words, the two methods I claimed work with filenames with any character in them do indeed work for a file whose name contains a space, a newline, and a non-ASCII character. |
* rpl: update to 1.10 Changes upstream as discussed in kcoyner/rpl#7 - manpage missing because of a missing python package.
Hello,
@rrthomas has been maintaining a friendly fork of
rpl
over at https://github.com/rrthomas/rpl. That is also the version included in Debian.Would you allow @rrthomas to make that fork official – e.g. by making them a collaborator here, or even transferring the repo?
The text was updated successfully, but these errors were encountered: