Re: 'find' portability problem
Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan I think so. The find command on Solaris 2.7 prints all files Stephan otherwise. I'm not sure if this makes sense in any case, but Stephan it is like that. Old BSD find did nothing when no action like Stephan -print or -ls was missing. Stephan I would use -print. It's save and documented. Thanks a lot. I applied this change. JMarc
Re: 'find' portability problem
> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> I think so. The find command on Solaris 2.7 prints all files Stephan> otherwise. I'm not sure if this makes sense in any case, but Stephan> it is like that. Old BSD find did nothing when no action like Stephan> "-print" or "-ls" was missing. Stephan> I would use "-print". It's save and documented. Thanks a lot. I applied this change. JMarc
Re: 'find' portability problem
Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan as far as I know I would do it like that: Stephan find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. JMarc
Re: 'find' portability problem
On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan as far as I know I would do it like that: Stephan find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. It works for me. Bennett
Re: 'find' portability problem
Bennett == Bennett Helm [EMAIL PROTECTED] writes: Bennett On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan as far as I know I would do it like that: Stephan find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. Bennett It works for me. Thanks. I will have a go at it when I come back in august. JMarc
Re: 'find' portability problem
Jean-Marc Lasgouttes wrote: Bennett == Bennett Helm [EMAIL PROTECTED] writes: Bennett On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan as far as I know I would do it like that: Stephan find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. Bennett It works for me. Hello JMarc, hello Bennett, if you call me a nit-picker... maybe, you're right. But: I wrote find path-name-list \( -name foo -o -name bar \) -print. The command find src \( -name '*.[Cch]' -or -name '*.C.in' \) is a (unneeded) GNU-ism. The standard Unix find doesn't like the -or. You have to use the -o here in case it should stay portable. Greets, Stephan
Re: 'find' portability problem
Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan if you call me a nit-picker... maybe, you're right. But: Stephan I wrote find path-name-list \( -name foo -o -name bar \) Stephan -print. Stephan The command find src \( -name '*.[Cch]' -or -name '*.C.in' Stephan \) is a (unneeded) GNU-ism. The standard Unix find doesn't Stephan like the -or. You have to use the -o here in case it Stephan should stay portable. No, you are not a nitpicker , since the problem we have right now is related to portability. So we shall use -o. What about -print? Is it really necessary? JMarc
Re: 'find' portability problem
Jean-Marc Lasgouttes wrote: Stephan == Stephan Witt [EMAIL PROTECTED] writes: Stephan if you call me a nit-picker... maybe, you're right. But: Stephan I wrote find path-name-list \( -name foo -o -name bar \) Stephan -print. Stephan The command find src \( -name '*.[Cch]' -or -name '*.C.in' Stephan \) is a (unneeded) GNU-ism. The standard Unix find doesn't Stephan like the -or. You have to use the -o here in case it Stephan should stay portable. No, you are not a nitpicker , since the problem we have right now is related to portability. So we shall use -o. Thanks. Some people get nervous when I tell them such things. :) What about -print? Is it really necessary? I think so. The find command on Solaris 2.7 prints all files otherwise. I'm not sure if this makes sense in any case, but it is like that. Old BSD find did nothing when no action like -print or -ls was missing. I would use -print. It's save and documented. Greets, Stephan
Re: 'find' portability problem
> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> as far as I know I would do it like that: Stephan> find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. JMarc
Re: 'find' portability problem
On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> as far as I know I would do it like that: Stephan> find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. It works for me. Bennett
Re: 'find' portability problem
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes: Bennett> On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: >>> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: >> Stephan> as far as I know I would do it like that: >> Stephan> find path-name-list \( -name foo -o -name bar \) -print >> Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or >> -name '*.C.in' \) work? If it does, I will use that. Bennett> It works for me. Thanks. I will have a go at it when I come back in august. JMarc
Re: 'find' portability problem
Jean-Marc Lasgouttes wrote: "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes: Bennett> On Jul 15, 2004, at 9:10 AM, Jean-Marc Lasgouttes wrote: "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> as far as I know I would do it like that: Stephan> find path-name-list \( -name foo -o -name bar \) -print Indeed, thanks. Nirmal, would find src \( -name '*.[Cch]' -or -name '*.C.in' \) work? If it does, I will use that. Bennett> It works for me. Hello JMarc, hello Bennett, if you call me a nit-picker... maybe, you're right. But: I wrote "find path-name-list \( -name foo -o -name bar \) -print". The command "find src \( -name '*.[Cch]' -or -name '*.C.in' \)" is a (unneeded) GNU-ism. The standard Unix find doesn't like the "-or". You have to use the "-o" here in case it should stay portable. Greets, Stephan
Re: 'find' portability problem
> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> if you call me a nit-picker... maybe, you're right. But: Stephan> I wrote "find path-name-list \( -name foo -o -name bar \) Stephan> -print". Stephan> The command "find src \( -name '*.[Cch]' -or -name '*.C.in' Stephan> \)" is a (unneeded) GNU-ism. The standard Unix find doesn't Stephan> like the "-or". You have to use the "-o" here in case it Stephan> should stay portable. No, you are not a nitpicker , since the problem we have right now is related to portability. So we shall use -o. What about -print? Is it really necessary? JMarc
Re: 'find' portability problem
Jean-Marc Lasgouttes wrote: "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes: Stephan> if you call me a nit-picker... maybe, you're right. But: Stephan> I wrote "find path-name-list \( -name foo -o -name bar \) Stephan> -print". Stephan> The command "find src \( -name '*.[Cch]' -or -name '*.C.in' Stephan> \)" is a (unneeded) GNU-ism. The standard Unix find doesn't Stephan> like the "-or". You have to use the "-o" here in case it Stephan> should stay portable. No, you are not a nitpicker , since the problem we have right now is related to portability. So we shall use -o. Thanks. Some people get nervous when I tell them such things. :) What about -print? Is it really necessary? I think so. The find command on Solaris 2.7 prints all files otherwise. I'm not sure if this makes sense in any case, but it is like that. Old BSD find did nothing when no action like "-print" or "-ls" was missing. I would use "-print". It's save and documented. Greets, Stephan
'find' portability problem (was Re: LyX and OS X)
Nirmal == Nirmal Govind [EMAIL PROTECTED] writes: Hello lyx-devel, I continue this private discussion with Nirmal and Bennett here, since I am sure somebody will come up with the one true find syntax we need. The problem is that compilation hangs in po, and the reason is the following find invokation in po/Makefile.in.in: find src -regex .*\\.\\(C\\|c\\|h\\|C\\.in\\) -print Nirmal My bad.. the correct syntax should be: Nirmal find src \( -regex .*\\.\\C -or -regex .*\\.\\c -or -regex Nirmal .*\\.\\h -or -regex .*\\C\\.in \) -print Nirmal This works well and from man find on OS X, there does not seem Nirmal to be support for the | syntax for the logical OR (I'm pasting Nirmal some of the relevant parts of man find below).. I took a look at the find man page which reads: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/find.1.html] -regex pattern True if the whole path of the file matches pattern using regular expression. To match a file named ``./foo/xyzzy'', you can use the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not ``xyzzy'' or ``/foo/''. This is OK. However, there is also this option about the type of regular expressions: -E Interpret regular expressions followed by -regex and -iregex options as extended (modern) regular expressions rather than basic regular expressions (BRE's). The re_format(7) manual page fully describes both formats. So, what is a basic RE according to apple? The man page re_format says: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/re_format.7.html] Obsolete (``basic'') regular expressions differ in several respects. `|' is an ordinary character and there is no equivalent for its functionality. [...] So it seems that Darwin's find cannot handle our find regular expression, because BRE cannot do `or'. OTOH, it seems that we cannot use EREs with GNU find. Except for the .C.in case, it seems that we could use find src -name '*.[Cch]' -print (this is basically what we did in 1.3.x) So what is the truly portable way to do a ``or'' in find-world? Shall we use \( foo -or bar \)? JMarc
Re: 'find' portability problem (was Re: LyX and OS X)
Jean-Marc Lasgouttes wrote: Nirmal == Nirmal Govind [EMAIL PROTECTED] writes: Hello lyx-devel, I continue this private discussion with Nirmal and Bennett here, since I am sure somebody will come up with the one true find syntax we need. The problem is that compilation hangs in po, and the reason is the following find invokation in po/Makefile.in.in: find src -regex .*\\.\\(C\\|c\\|h\\|C\\.in\\) -print Nirmal My bad.. the correct syntax should be: Nirmal find src \( -regex .*\\.\\C -or -regex .*\\.\\c -or -regex Nirmal .*\\.\\h -or -regex .*\\C\\.in \) -print Nirmal This works well and from man find on OS X, there does not seem Nirmal to be support for the | syntax for the logical OR (I'm pasting Nirmal some of the relevant parts of man find below).. I took a look at the find man page which reads: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/find.1.html] -regex pattern True if the whole path of the file matches pattern using regular expression. To match a file named ``./foo/xyzzy'', you can use the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not ``xyzzy'' or ``/foo/''. This is OK. However, there is also this option about the type of regular expressions: -E Interpret regular expressions followed by -regex and -iregex options as extended (modern) regular expressions rather than basic regular expressions (BRE's). The re_format(7) manual page fully describes both formats. So, what is a basic RE according to apple? The man page re_format says: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/re_format.7.html] Obsolete (``basic'') regular expressions differ in several respects. `|' is an ordinary character and there is no equivalent for its functionality. [...] So it seems that Darwin's find cannot handle our find regular expression, because BRE cannot do `or'. OTOH, it seems that we cannot use EREs with GNU find. Except for the .C.in case, it seems that we could use find src -name '*.[Cch]' -print (this is basically what we did in 1.3.x) So what is the truly portable way to do a ``or'' in find-world? Shall we use \( foo -or bar \)? Hi Jean-Marc, as far as I know I would do it like that: find path-name-list \( -name foo -o -name bar \) -print Stephan
'find' portability problem (was Re: LyX and OS X)
> "Nirmal" == Nirmal Govind <[EMAIL PROTECTED]> writes: Hello lyx-devel, I continue this private discussion with Nirmal and Bennett here, since I am sure somebody will come up with the one true find syntax we need. The problem is that compilation hangs in po, and the reason is the following find invokation in po/Makefile.in.in: find src -regex ".*\\.\\(C\\|c\\|h\\|C\\.in\\)" -print Nirmal> My bad.. the correct syntax should be: Nirmal> find src \( -regex ".*\\.\\C" -or -regex ".*\\.\\c" -or -regex Nirmal> ".*\\.\\h" -or -regex ".*\\C\\.in" \) -print Nirmal> This works well and from man find on OS X, there does not seem Nirmal> to be support for the | syntax for the logical OR (I'm pasting Nirmal> some of the relevant parts of man find below).. I took a look at the find man page which reads: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/find.1.html] -regex pattern True if the whole path of the file matches pattern using regular expression. To match a file named ``./foo/xyzzy'', you can use the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not ``xyzzy'' or ``/foo/''. This is OK. However, there is also this option about the type of regular expressions: -E Interpret regular expressions followed by -regex and -iregex options as extended (modern) regular expressions rather than basic regular expressions (BRE's). The re_format(7) manual page fully describes both formats. So, what is a basic RE according to apple? The man page re_format says: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/re_format.7.html] Obsolete (``basic'') regular expressions differ in several respects. `|' is an ordinary character and there is no equivalent for its functionality. [...] So it seems that Darwin's find cannot handle our find regular expression, because BRE cannot do `or'. OTOH, it seems that we cannot use EREs with GNU find. Except for the .C.in case, it seems that we could use find src -name '*.[Cch]' -print (this is basically what we did in 1.3.x) So what is the truly portable way to do a ``or'' in find-world? Shall we use "\( foo -or bar \)"? JMarc
Re: 'find' portability problem (was Re: LyX and OS X)
Jean-Marc Lasgouttes wrote: "Nirmal" == Nirmal Govind <[EMAIL PROTECTED]> writes: Hello lyx-devel, I continue this private discussion with Nirmal and Bennett here, since I am sure somebody will come up with the one true find syntax we need. The problem is that compilation hangs in po, and the reason is the following find invokation in po/Makefile.in.in: find src -regex ".*\\.\\(C\\|c\\|h\\|C\\.in\\)" -print Nirmal> My bad.. the correct syntax should be: Nirmal> find src \( -regex ".*\\.\\C" -or -regex ".*\\.\\c" -or -regex Nirmal> ".*\\.\\h" -or -regex ".*\\C\\.in" \) -print Nirmal> This works well and from man find on OS X, there does not seem Nirmal> to be support for the | syntax for the logical OR (I'm pasting Nirmal> some of the relevant parts of man find below).. I took a look at the find man page which reads: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/find.1.html] -regex pattern True if the whole path of the file matches pattern using regular expression. To match a file named ``./foo/xyzzy'', you can use the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not ``xyzzy'' or ``/foo/''. This is OK. However, there is also this option about the type of regular expressions: -E Interpret regular expressions followed by -regex and -iregex options as extended (modern) regular expressions rather than basic regular expressions (BRE's). The re_format(7) manual page fully describes both formats. So, what is a basic RE according to apple? The man page re_format says: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/re_format.7.html] Obsolete (``basic'') regular expressions differ in several respects. `|' is an ordinary character and there is no equivalent for its functionality. [...] So it seems that Darwin's find cannot handle our find regular expression, because BRE cannot do `or'. OTOH, it seems that we cannot use EREs with GNU find. Except for the .C.in case, it seems that we could use find src -name '*.[Cch]' -print (this is basically what we did in 1.3.x) So what is the truly portable way to do a ``or'' in find-world? Shall we use "\( foo -or bar \)"? Hi Jean-Marc, as far as I know I would do it like that: find path-name-list \( -name foo -o -name bar \) -print Stephan
