Title: monday
Elk extract that helps you in the bed with the girl.
Learn about it here
I don't want this
Acts papers undertaken broad Majesty". known papers current definition.
White described website. undertaken the topics aid numbered Documents contains
Papers. public Statutory described signif
In autoconf 2.58, ./lib/autoconf/fortran.m4 has a list of Fortran 77,
90, and 95 compilers that initialize _AC_F77_FC, _AC_F90_FC, and
_AC_F95_FC.
The _AC_F95_FC list contains ifc:
# ifc: Intel Fortran 95 compiler for Linux/x86
Effective yesterday with the release of version 8.0 of the
Lose weight the easier way!"IT'S NOT A DIET IT'S A PATCH"
Order today and get 5 month supply for the price of 4!
* No side effects* Completely safe
* 100% Móney Back Guarántee* Discretely shipped
* Order shipped same day
Read all about it
and order here
I don't want this
Hi,
When config.status builds "FILE" from "FILE.in" it always creates
non-executable files. The attached patch will "chmod +x FILE"
if "test -x FILE.in" (specifically if "test -x" any of the input files).
BTW subversions.gnu.org:cvspserver is unreachable for several days.
This CVS pserver addres
Jan Kratochvil wrote:
When config.status builds "FILE" from "FILE.in" it always creates
non-executable files. The attached patch will "chmod +x FILE"
if "test -x FILE.in" (specifically if "test -x" any of the input files).
Unfortunately, older 'test' commands do not recognize the -x option,
theref
Hi,
On Wed, 10 Dec 2003 16:46:35 +0100, Eric Sunshine wrote:
...
> > The attached patch will "chmod +x FILE"
> > if "test -x FILE.in" (specifically if "test -x" any of the input files).
>
> Unfortunately, older 'test' commands do not recognize the -x option,
Just a try - this is also forbidden?
Jan Kratochvil wrote:
On Wed, 10 Dec 2003 16:46:35 +0100, Eric Sunshine wrote:
Unfortunately, older 'test' commands do not recognize the -x option,
Just a try - this is also forbidden?: if ls -ld $f | grep -q '^...x'; then
The grep -q option is unportable. Autoconf works around this issue by
red
Hi,
On Wed, 10 Dec 2003 17:55:04 +0100, Eric Sunshine wrote:
...
> At the very least, it would be a good idea to
> only use "ls -ld" after checking that such usage is valid (i.e. ensure
> that "ls -ld" actually works, and works as intended on the target platform).
As the possible 'keep executa
Eric Sunshine <[EMAIL PROTECTED]> wrote:
> The '^' and '.' tokens in the grep expression also are not necessarily
> portable since they are considered part of the "extended" regular
> expression syntax which is provided by 'egrep' or 'grep -E'.
Not according to grep's documentation.
paul
Paul Jarc wrote:
Eric Sunshine <[EMAIL PROTECTED]> wrote:
The '^' and '.' tokens in the grep expression also are not necessarily
portable since they are considered part of the "extended" regular
expression syntax which is provided by 'egrep' or 'grep -E'.
Not according to grep's documentation.
In t
Jan Kratochvil wrote:
On Wed, 10 Dec 2003 17:55:04 +0100, Eric Sunshine wrote:
At the very least, it would be a good idea to
only use "ls -ld" after checking that such usage is valid (i.e. ensure
that "ls -ld" actually works, and works as intended on the target platform).
As the possible 'keep ex
Eric Sunshine <[EMAIL PROTECTED]> wrote:
> In the grep documentation on NextStep, for instance, the '^' and '.'
> tokens are mentioned only in the 'egrep' section.
Is the grep program's behavior consistent with that? If so, the
"Limitations of Usual Tools" section of autoconf's manual should
prob
Paul Jarc wrote:
Eric Sunshine <[EMAIL PROTECTED]> wrote:
In the grep documentation on NextStep, for instance, the '^' and '.'
tokens are mentioned only in the 'egrep' section.
Is the grep program's behavior consistent with that? If so, the
"Limitations of Usual Tools" section of autoconf's manual
Hi,
On Wed, 10 Dec 2003 18:27:49 +0100, Eric Sunshine wrote:
> Jan Kratochvil wrote:
...
> > As the possible 'keep executable' feature would be dependent upon by the
> > package there is no way to make it optional according to the host platform.
>
> What I meant was that if 'ls -ld' behaves "corr
> Hi,
> On Wed, 10 Dec 2003 17:55:04 +0100, Eric Sunshine wrote:
> ...
>> At the very least, it would be a good idea to
>> only use "ls -ld" after checking that such usage is valid (i.e. ensure
>> that "ls -ld" actually works, and works as intended on the target platform).
> As the possi
Akim Demaille wrote:
How about cp FILE.in FILE and then perform the transformation from
FILE.in's contents to (>) FILE?
This will not work correctly on Windows. At best, it will throw an
error because FILE is locked (being read by sed) while the > is trying
to open it for writing. At worst, you
On Wed, 10 Dec 2003, Akim Demaille wrote:
> > On Wed, 10 Dec 2003 17:55:04 +0100, Eric Sunshine wrote:
> > ...
> >> At the very least, it would be a good idea to
> >> only use "ls -ld" after checking that such usage is valid (i.e. ensure
> >> that "ls -ld" actually works, and works as intende
Eric Sunshine <[EMAIL PROTECTED]> wrote:
> Akim Demaille wrote:
>> How about cp FILE.in FILE and then perform the transformation from
>> FILE.in's contents to (>) FILE?
>
> This will not work correctly on Windows. At best, it will throw an
> error because FILE is locked (being read by sed) while t
>> How about cp FILE.in FILE and then perform the transformation from
>> FILE.in's contents to (>) FILE?
> Good idea, but it will fail if FILE.in is read-only.
chmod +w :)
On Wed, 10 Dec 2003, Eric Sunshine wrote:
> Akim Demaille wrote:
> > How about cp FILE.in FILE and then perform the transformation from
> > FILE.in's contents to (>) FILE?
>
> This will not work correctly on Windows. At best, it will throw an
> error because FILE is locked (being read by sed) whi
On Wed, 10 Dec 2003, Akim Demaille wrote:
>
> >> How about cp FILE.in FILE and then perform the transformation from
> >> FILE.in's contents to (>) FILE?
>
> > Good idea, but it will fail if FILE.in is read-only.
>
> chmod +w :)
Which will fail if the current user does not have the right to upd
Hi,
On Wed, 10 Dec 2003 19:14:00 +0100, Bob Friesenhahn wrote:
> On Wed, 10 Dec 2003, Akim Demaille wrote:
...
> > chmod +w :)
>
> Which will fail if the current user does not have the right to update
> the file (e.g. owned by another user ID). This may seem unusual, but
> it can be expected for
On Wed, 10 Dec 2003, Jan Kratochvil wrote:
> On Wed, 10 Dec 2003 19:14:00 +0100, Bob Friesenhahn wrote:
> > On Wed, 10 Dec 2003, Akim Demaille wrote:
> ...
> > > chmod +w :)
> >
> > Which will fail if the current user does not have the right to update
> > the file (e.g. owned by another user ID).
Eric Sunshine wrote:
>
> Jan Kratochvil wrote:
> > Just a try - this is also forbidden?: if ls -ld $f | grep -q '^...x'; then
>
> The grep -q option is unportable. Autoconf works around this issue by
>
> The '^' and '.' tokens in the grep expression also are not Instead,
> usage would
On Wed, Dec 10, 2003 at 11:55:04AM -0500, Eric Sunshine wrote:
> The '^' and '.' tokens in the grep expression [...]
>
> [...] only use "ls -ld" after checking that such usage is valid
I'm 95% certain that each of these worked in 6th-Edition Bell
Labs UNIX, so it'd have to be a truly perverse pl
On Wed, 10 Dec 2003 13:11:38 -0500, Paul Jarc wrote:
> Eric Sunshine <[EMAIL PROTECTED]> wrote:
> > This will not work correctly on Windows. At best, it will throw an
> > error because FILE is locked (being read by sed) while the > is trying
> > to open it for writing.
> FILE wouldn't be read by s
On Wed, 10 Dec 2003 12:42:26 -0600 (CST), Bob Friesenhahn wrote:
> > This 'read-only another user ID' applies to FILE.in but not to FILE -
> > FILE must be writable by our (>). Is it OK this way?
> > cp srcdir/FILE.in builddir/FILE
> > chmod +w builddir/FILE
> > sed ... builddir/FILE
> Seems good t
On Wed, Dec 10, 2003 at 02:21:11PM -0500, Eric Siegerman wrote:
> On Wed, Dec 10, 2003 at 11:55:04AM -0500, Eric Sunshine wrote:
> > The '^' and '.' tokens in the grep expression [...]
> >
> > [...] only use "ls -ld" after checking that such usage is valid
>
> I'm 95% certain that each of these
On Wed, 10 Dec 2003 15:20:48 -0500, Daniel Jacobowitz wrote:
> Well, systems where ls -ld behaves differently aren't all that
> uncommon. For instance, on some AFS installations you'll get only
> three bits of permission instead of the usual nine. Personally, I'd
> just mark everything executable
On Wed, 10 Dec 2003 10:03:35 -0800, Bruce Korb wrote:
> This is plain nutty.
Indeed. Portability issues almost always are. At any rate, I was not
suggesting that that approach be used, but rather was pointing out potential
problems in the proposal, along with some possible solutions. I am a
Hi,
I rewrote those several lines of code - does it look OK now?
It appears to execute fine.
Regards,
Lace
diff -u -ru autoconf-2.57-orig/lib/autoconf/status.m4
autoconf-2.57/lib/autoconf/status.m4
--- autoconf-2.57-orig/lib/autoconf/status.m4 Tue Nov 12 11:54:46 2002
+++ autoconf-2.57/lib/a
On Wed, 10 Dec 2003, Jan Kratochvil wrote:
>
> I rewrote those several lines of code - does it look OK now?
> It appears to execute fine.
dnlmv $tmp/out $ac_file
dnl fi
if test x"$ac_file" != x-; then
-mv $tmp/out $ac_file
+rm -f $ac_file
+dnl Keep 'executable' attribute.
+f
On Wed, 10 Dec 2003 16:03:49 -0600 (CST), Bob Friesenhahn wrote:
> On Wed, 10 Dec 2003, Jan Kratochvil wrote:
> if test x"$ac_file" != x-; then
> -mv $tmp/out $ac_file
> +rm -f $ac_file
> +dnl Keep 'executable' attribute.
> +for f in $ac_file_inputs; do
> + cp $f $ac_file
> +
On Wed, Dec 10, 2003 at 03:20:48PM -0500, Daniel Jacobowitz wrote:
> Well, systems where ls -ld behaves differently aren't all that
> uncommon. For instance, on some AFS installations you'll get only
> three bits of permission instead of the usual nine.
Yikes! Ok, I stand corrected.
Of course,
Hi,
On Wed, 10 Dec 2003 23:50:02 +0100, Eric Sunshine wrote:
...
> composite output file. Of course, that fails with this above scheme since
> the net result is that it clones only the execute permission of the very last
> file in the ac_file_inputs list. It would probably make more sense to
We're pleased to announce the release of Automake 1.8.
Automake is a tool for automatically generating `Makefile.in's
suitable for use with Autoconf, compliant with the GNU Makefile
standards, and portable to various make implementations.
This release contains many bug fixes and improvements. Th
36 matches
Mail list logo
