find backward

QNX Newsgroups (Archives) qdn.public.qnxrtp.applications
21

“Dean Douthat” <ddouthat@faac.com> wrote in message
news:3BE2D5F3.DB594892@faac.com…

Mario Charest wrote:

“Kris Eric Warkentin” <> kewarken@qnx.com> > wrote in message
news:9rs7tb$mf7$> 1@nntp.qnx.com> …
What about a shell script like this?

I want to do this within a makefile without having to invoke any non
system
script/program

Preceed first line with ‘@’ and escape all newlines except last one with
‘’.

This works when run as a result of a rule, but I’m trying to assign a
variable,
before any rules.


22

Mario Charest wrote:

“Dean Douthat” <> ddouthat@faac.com> > wrote in message
news:> 3BE2D5F3.DB594892@faac.com> …


Mario Charest wrote:

“Kris Eric Warkentin” <> kewarken@qnx.com> > wrote in message
news:9rs7tb$mf7$> 1@nntp.qnx.com> …
What about a shell script like this?

I want to do this within a makefile without having to invoke any non
system
script/program

Preceed first line with ‘@’ and escape all newlines except last one with
‘’.

This works when run as a result of a rule, but I’m trying to assign a
variable,
before any rules.
\

Oh, in that case, perhaps rename make as make.real and construct a shell
script called make which calls make.real as:

make.real variable_to_be_set=$(shell commands) $1

Would that do what you want?

23

Oh, in that case, perhaps rename make as make.real and construct a shell
script called make which calls make.real as:

make.real variable_to_be_set=$(shell commands) $1


Would that do what you want?

Not quite since it would require the existance of an external
script, “commands” in you example.

\

24

Mario Charest wrote:

Oh, in that case, perhaps rename make as make.real and construct a shell
script called make which calls make.real as:

make.real variable_to_be_set=$(shell commands) $1


Would that do what you want?

Not quite since it would require the existance of an external
script, “commands” in you example.

No script other than the make script is needed. The $(shell commands) are
in-line within the make.real command line itself. The make script is, of
course, on the normal path where make normally resides (/bin/make).

25

“Dean Douthat” <ddouthat@faac.com> wrote in message
news:3BE6A535.572F5C38@faac.com…

Mario Charest wrote:

Oh, in that case, perhaps rename make as make.real and construct a
shell
script called make which calls make.real as:

make.real variable_to_be_set=$(shell commands) $1


Would that do what you want?

Not quite since it would require the existance of an external
script, “commands” in you example.



No script other than the make script is needed. The $(shell commands) are
in-line within the make.real command line itself. The make script is, of
course, on the normal path where make normally resides (/bin/make).

If I understand correctly “commands” would be an inline script right?
I haven’t been able to get this test case going:

dirs=$(shell export test_var=“abcd”; echo $$test_var)

\

26

Mario Charest wrote:

“Dean Douthat” <> ddouthat@faac.com> > wrote in message
news:> 3BE6A535.572F5C38@faac.com> …


Mario Charest wrote:

Oh, in that case, perhaps rename make as make.real and construct a
shell
script called make which calls make.real as:

make.real variable_to_be_set=$(shell commands) $1


Would that do what you want?

Not quite since it would require the existance of an external
script, “commands” in you example.



No script other than the make script is needed. The $(shell commands) are
in-line within the make.real command line itself. The make script is, of
course, on the normal path where make normally resides (/bin/make).

If I understand correctly “commands” would be an inline script right?
I haven’t been able to get this test case going:

dirs=$(shell export test_var=“abcd”; echo $$test_var)

Try this:

dirs=$(export test_var=“abcd”; echo ${test_var}); print $dirs

27

Dean Douthat wrote:

Mario Charest wrote:

“Dean Douthat” <> ddouthat@faac.com> > wrote in message
news:> 3BE6A535.572F5C38@faac.com> …


Mario Charest wrote:

Oh, in that case, perhaps rename make as make.real and construct a
shell
script called make which calls make.real as:

make.real variable_to_be_set=$(shell commands) $1


Would that do what you want?

Not quite since it would require the existance of an external
script, “commands” in you example.



No script other than the make script is needed. The $(shell commands) are
in-line within the make.real command line itself. The make script is, of
course, on the normal path where make normally resides (/bin/make).

If I understand correctly “commands” would be an inline script right?
I haven’t been able to get this test case going:

dirs=$(shell export test_var=“abcd”; echo $$test_var)



Try this:

dirs=$(export test_var=“abcd”; echo ${test_var}); print $dirs

Note: the second test_var is surrounded by squiggly brackets (braces) not
parentheses. It’s hard to tell in some fonts.

28

Try this:

dirs=$(export test_var=“abcd”; echo ${test_var}); print $dirs

Note: the second test_var is surrounded by squiggly brackets (braces) not
parentheses. It’s hard to tell in some fonts.

This works fine from a shell but not from within a makefile ex:

dirs=$(export test_var=“abcd”; echo ${test_var});
default:
echo $(dirs)

In this case I would expect echo to spit out abcd but instead dirs is
empty. From my understanding of make, that’s to be expected since
$(export…) isn’t a variable nor a make supported function. Thus
it gets resolved to nothing :wink:

Thanks!

29

Mario Charest wrote:

Try this:

dirs=$(export test_var=“abcd”; echo ${test_var}); print $dirs

Note: the second test_var is surrounded by squiggly brackets (braces) not
parentheses. It’s hard to tell in some fonts.

This works fine from a shell but not from within a makefile ex:

dirs=$(export test_var=“abcd”; echo ${test_var});
default:
echo $(dirs)

In this case I would expect echo to spit out abcd but instead dirs is
empty. From my understanding of make, that’s to be expected since
$(export…) isn’t a variable nor a make supported function. Thus
it gets resolved to nothing > :wink:

Thanks!

Don’t put it in your make productions. Rather, put it in a shell script called
“make” located at /bin/make. As a command-line argument to the real make
command (called make.real or some such), it will set the make macro dirs to the
value you want. Look several posts back where I discuss make.real etc.

30

Don’t put it in your make productions. Rather, put it in a shell script
called
“make” located at /bin/make. As a command-line argument to the real make
command (called make.real or some such), it will set the make macro dirs
to the
value you want. Look several posts back where I discuss make.real etc.

One of my goal is to NOT have to setup anything for development.
I want the developpers to install QNX6, check the source out (along with
make files etc) and be ready to compile the source by simply lauching make.

I’ve created a bfind program that has to be located somewhere in
the path. Works fine, but I would like to totaly get rid of the need for an
external program or some sort of setup procedure.

  • Mario
31

Mario Charest <mcharest@clipzinformatic.com> wrote:
…

This works fine from a shell but not from within a makefile ex:

dirs=$(export test_var=“abcd”; echo ${test_var});
default:
echo $(dirs)

In this case I would expect echo to spit out abcd but instead dirs is
empty. From my understanding of make, that’s to be expected since
$(export…) isn’t a variable nor a make supported function. Thus
it gets resolved to nothing > :wink:

This works for me:

dirs=$(shell export test_var=“abcd”; echo $${test_var});
default:
echo $(dirs)

–
Wojtek Lerch QNX Software Systems Ltd.

32

Dean Douthat wrote:

I believe eq in second test should be ‘=’, that is,

[ “$parent” = “$dir” ] && break

Right. Too much perl programming!

Also, I noted that:

[ -f //.boot ]

returns false whereas:

[ -f /.boot ]

returns true.

Bug in ksh?

//.boot is not a valid path as far as I know. I’d say this is
a bug in ‘dirname’ for returning ‘//’ for dirname //1/.

-Norton

33

Mario Charest wrote:

I’ve created a bfind program that has to be located somewhere in
the path. Works fine, but I would like to totaly get rid of the need for an
external program or some sort of setup procedure.

Mario,

Why your aversion to setup? I’m just curious because it seems that
most source packages require some level of configuration, e.g.
./configure or something simpler.

I’d say the closest thing to a standard approach would be to
create a shell script called Makefile.sh which writes out the
real Makefile. That has to be executed once before you run make.

With GNU make, there is also a way to make the Makefile depend
on Makefile.sh, and actually restart, but I can’t tell you how
it’s done.

34

Norton Allen wrote:

Dean Douthat wrote:

I believe eq in second test should be ‘=’, that is,

[ “$parent” = “$dir” ] && break

Right. Too much perl programming!


Also, I noted that:

[ -f //.boot ]

returns false whereas:

[ -f /.boot ]

returns true.

Bug in ksh?

//.boot is not a valid path as far as I know. I’d say this is
a bug in ‘dirname’ for returning ‘//’ for dirname //1/.

-Norton

Hmm. I had thought a doubled ‘/’ was supposed to be treated as if
condensed to a single one. QSSL, any comment?

35

Dean Douthat wrote:

Norton Allen wrote:

Dean Douthat wrote:

I believe eq in second test should be ‘=’, that is,

[ “$parent” = “$dir” ] && break

Right. Too much perl programming!


Also, I noted that:

[ -f //.boot ]

returns false whereas:

[ -f /.boot ]

returns true.

Bug in ksh?

//.boot is not a valid path as far as I know. I’d say this is
a bug in ‘dirname’ for returning ‘//’ for dirname //1/.

-Norton

Hmm. I had thought a doubled ‘/’ was supposed to be treated as if
condensed to a single one. QSSL, any comment?

Just to re-emphasize, I am talking about QNX4 ksh and dirname, not
QNX6. [ -f //.boot ] returns 0 on QNX6, just as [ -f /.boot] does. I
believe the QNX6 behavior to be correct.

36

“Norton Allen” <allen@huarp.harvard.edu> wrote in message
news:3BE97296.A9166386@huarp.harvard.edu…

Mario Charest wrote:
I’ve created a bfind program that has to be located somewhere in
the path. Works fine, but I would like to totaly get rid of the need
for an
external program or some sort of setup procedure.

Mario,

Hello Norton,



Why your aversion to setup? I’m just curious because it seems that
most source packages require some level of configuration, e.g.
./configure or something simpler.

I have to admit I didn’t consider using something like configure.
On the few programs I ported that used configure, it
never work right out of the box… Everytime I wanted to fix the config
setup
solve the issue, I was always repelled by the complexity.
I guess that is why my brain didn’t consider it as an option.


I’d say the closest thing to a standard approach would be to
create a shell script called Makefile.sh which writes out the
real Makefile. That has to be executed once before you run make.

Thanks to the participant of this thread I was able to do:

ROOTPATH = $(shell let cnt=0;
while [ ! -f $${common_dir}common.mk ]; do
export common_dir=…/$${common_dir}; let cnt=$${cnt}+1;
if test $${cnt} -eq 20 ; then exit 2; fi;
done;
echo $${common_dir} )

With GNU make, there is also a way to make the Makefile depend
on Makefile.sh, and actually restart, but I can’t tell you how
it’s done.

Right now I’m happy with the setup. The project consists of multiple
programs, each program reside at various level of directory in the source
tree.
It’s now possible to go in any program and run make, without any other
requirement then to run make. I like that!!! Program can live at any
level, or even be move from one level to another without a single
change.

The Makefile of each program looks like:

Specify root path (where common.mk is)

ROOTPATH = $(shell let cnt=0;
while [ ! -f $${common_dir}common.mk ]; do
export common_dir=…/$${common_dir}; let cnt=$${cnt}+1;
if test $${cnt} -eq 20 ; then exit 2; fi;
done;
echo $${common_dir} )

Specify target type

#################################################

DO NOT CHANGE AFTER THIS

#################################################

include $(ROOTPATH)/common.mk


All the magic is in common.mk, which is common to the whole project.


I have to thank Brian, I learned so much about the power of makefile
looking at his stuff… I just love dumping a c file in a directory and
have it included in the list of file to build automaticly, !!!

37

Dean Douthat <ddouthat@faac.com> wrote:
…

Hmm. I had thought a doubled ‘/’ was supposed to be treated as if
condensed to a single one. QSSL, any comment?

Just to re-emphasize, I am talking about QNX4 ksh and dirname, not
QNX6. [ -f //.boot ] returns 0 on QNX6, just as [ -f /.boot] does. I
believe the QNX6 behavior to be correct.

Two leading slashes are special under QNX4, but that’s not incorrect
behaviour. This is what the Unix98 specs have to say about this:

Multiple successive slashes are considered to be the same as one
slash. A pathname that begins with two successive slashes may be
interpreted in an implementation-dependent manner, although more
than two leading slashes are treated as a single slash.

–
Wojtek Lerch QNX Software Systems Ltd.

38

This was the rule in QNX4. I don’t know if RTP ever made tyhat promise.

–
Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Dean Douthat” <ddouthat@faac.com> wrote in message
news:3BE97980.33A0F3C2@faac.com…

Hmm. I had thought a doubled ‘/’ was supposed to be treated as if
condensed to a single one. QSSL, any comment?

39

Wojtek Lerch wrote:

Dean Douthat <> ddouthat@faac.com> > wrote:
…
Hmm. I had thought a doubled ‘/’ was supposed to be treated as if
condensed to a single one. QSSL, any comment?

Just to re-emphasize, I am talking about QNX4 ksh and dirname, not
QNX6. [ -f //.boot ] returns 0 on QNX6, just as [ -f /.boot] does. I
believe the QNX6 behavior to be correct.

Two leading slashes are special under QNX4, but that’s not incorrect
behaviour. This is what the Unix98 specs have to say about this:

Multiple successive slashes are considered to be the same as one
slash. A pathname that begins with two successive slashes may be
interpreted in an implementation-dependent manner, although more
than two leading slashes are treated as a single slash.

[Sorry to be offline for so long…] Yes, the two leading slashes are
special. double slashes later in the path are the same as a single
slash, but for QNX4, the two leading slashes prefix the node number.
Since “dirname /” returns “/”, I would expect “dirname //1/” to return
“//1/”: i.e. a valid path.