Re: [gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.
On Saturday 13 April 2013 10:44:20 Michał Górny wrote: The edos2unix is quite useful when handling DOS-sourced packages. But since it's a bash function, you can't reasonably use it from within find invocation. And often you hit packages which are all flooded with CRLFs that you need to convert. That's why I'm suggesting to make edos2unix recursive. The posted patch changes the function to use find+sed for the substitution, passing given paths as the 'path' arguments to find. Whenever files are passed, nothing changes for ebuilds. If a directory is passed, find converts it recursively. The only potential breakage is when a non-file was passed and something weird was expected of it. i'm ambivalent on requiring the -r flag, so this LGTM as is -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.
The edos2unix is quite useful when handling DOS-sourced packages.
But since it's a bash function, you can't reasonably use it from within
find invocation. And often you hit packages which are all flooded with
CRLFs that you need to convert.
That's why I'm suggesting to make edos2unix recursive. The posted patch
changes the function to use find+sed for the substitution, passing given
paths as the 'path' arguments to find.
Whenever files are passed, nothing changes for ebuilds. If a directory
is passed, find converts it recursively. The only potential breakage is
when a non-file was passed and something weird was expected of it.
Any thoughts? If nobody opposes, I will commit the patch in 7 days.
---
gx86/eclass/eutils.eclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 467cf17..9e3a347 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -651,15 +651,16 @@ emktemp() {
}
# @FUNCTION: edos2unix
-# @USAGE: file [more files ...]
+# @USAGE: path [...]
# @DESCRIPTION:
# A handy replacement for dos2unix, recode, fixdos, etc... This allows you
# to remove all of these text utilities from DEPEND variables because this
-# is a script based solution. Just give it a list of files to convert and
-# they will all be changed from the DOS CRLF format to the UNIX LF format.
+# is a script based solution. Just give it a list of files or directories
+# to convert and they will all be changed from the DOS CRLF format
+# to the UNIX LF format recursively.
edos2unix() {
[[ $# -eq 0 ]] return 0
- sed -i 's/\r$//' -- $@ || die
+ find $@ -type f -exec sed -i 's/\r$//' -- {} + || die
}
# @FUNCTION: make_desktop_entry
--
1.8.1.5
Re: [gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix.
On Sat, Apr 13, 2013 at 10:44 AM, Michał Górny mgo...@gentoo.org wrote: The edos2unix is quite useful when handling DOS-sourced packages. But since it's a bash function, you can't reasonably use it from within find invocation. And often you hit packages which are all flooded with CRLFs that you need to convert. That's why I'm suggesting to make edos2unix recursive. The posted patch changes the function to use find+sed for the substitution, passing given paths as the 'path' arguments to find. Whenever files are passed, nothing changes for ebuilds. If a directory is passed, find converts it recursively. The only potential breakage is when a non-file was passed and something weird was expected of it. Any thoughts? If nobody opposes, I will commit the patch in 7 days. If used improperly, this could easily end up breaking binary files that happen to contain the '\r' byte. Maybe a DEPEND on dos2unix would be a better option in the case where many files must be converted. I don't think it is necessary to convert DOS text files unless they somehow break on a UNIX system. Shell scripts are a good example, as well as some autotools files. No need to convert README though. I would guess that this patch is a response to bug 465790. I'm ok with requiring that python scripts be in UNIX format, although the python interpreter seems to work with either format.
