regress.sh

Started by Patrick Welcheover 26 years ago9 messages
#1Patrick Welche
prlw1@newn.cam.ac.uk

The regression tests no longer seem to be using the "alternative" expected
files should they exist. I have run out of time looking for the cause, but
the story so far is in going from version 1.28-1.29 of regress.sh,
SYSTEM has gone from
... printf"%s-%s", $1, a[1] }'
to
... printf"%s-%s", $portname, a[1] }'
which means an example of output has changed from
i386-netbsd
to
i386-unknown-netbsd1.4-netbsd

Now, portname comes from PORTNAME=${os} in configure, which it appears ought
to be set in my case to

netbsd*)
os=bsd need_tas=no
case "$host_cpu" in
powerpc) elf=yes ;;
esac ;;

"bsd", so I would expect SYSTEM to be set to "bsd-netbsd" ?! which doesn't
seem right either...

Maybe "someone" could take another look?

Cheers,

Patrick

#2Noname
wieck@debis.com
In reply to: Patrick Welche (#1)
Re: [HACKERS] regress.sh

The regression tests no longer seem to be using the "alternative" expected
files should they exist. I have run out of time looking for the cause, but
the story so far is in going from version 1.28-1.29 of regress.sh,
SYSTEM has gone from
... printf"%s-%s", $1, a[1] }'
to
... printf"%s-%s", $portname, a[1] }'
which means an example of output has changed from
i386-netbsd
to
i386-unknown-netbsd1.4-netbsd

Now, portname comes from PORTNAME=${os} in configure, which it appears ought
to be set in my case to

netbsd*)
os=bsd need_tas=no
case "$host_cpu" in
powerpc) elf=yes ;;
esac ;;

"bsd", so I would expect SYSTEM to be set to "bsd-netbsd" ?! which doesn't
seem right either...

Maybe "someone" could take another look?

Ouch - looks like my recent change made while adding the
NUMERIC regression tests.

Looking at the actual sources I wonder why it can cause any
problems. At the very beginning I've added

portname=$1
export portname
shift

That variable is used ONLY ONCE in the awk line you're
quoting above. Prior to my changes, $1 was directly used as
argument to awk and all remaining args ignored silently by
regress.sh.

Is it required that variables local in regress.sh have upper
case? If so, why?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

#3Patrick Welche
prlw1@newn.cam.ac.uk
In reply to: Noname (#2)
Re: [HACKERS] regress.sh

Jan Wieck wrote:

Looking at the actual sources I wonder why it can cause any
problems. At the very beginning I've added

portname=$1
export portname
shift

That variable is used ONLY ONCE in the awk line you're
quoting above. Prior to my changes, $1 was directly used as
argument to awk and all remaining args ignored silently by
regress.sh.

Ah! portname=$1 means take $1 command line argument that the script
was called by.

awk -F\- '{ split($3,a,/[0-9]/); printf"%s-%s", $1, a[1] }'

$1 here is the 1st variable from the line split by awk. ie., $1 in the
first case is "sh" syntax, $1 in second case is "awk" syntax.

So now that I know there is no intentional magic, we can go back successfully
with

39c39
< SYSTEM=`../../config.guess | awk -F\- '{ split($3,a,/[0-9]/); printf"%s-%s", $portname, a[1] }'`
---

SYSTEM=`../../config.guess | awk -F\- '{ split($3,a,/[0-9]/); printf"%s-%s", $1, a[1] }'`

the only remaining query being:

*** expected/random.out Sun Aug 30 19:50:58 1998
--- results/random.out  Mon Jun 14 15:18:04 1999
***************
*** 19,23 ****
    WHERE random NOT BETWEEN 80 AND 120;
  random
  ------
! (0 rows)
--- 19,24 ----
    WHERE random NOT BETWEEN 80 AND 120;
  random
  ------
!    124
! (1 row)

?

Cheers,

Patrick

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Patrick Welche (#3)
Re: [HACKERS] regress.sh

wieck@debis.com (Jan Wieck) writes:

Is it required that variables local in regress.sh have upper
case? If so, why?

Nope, you just plain broke it. The only use of the script's $1
parameter is *above* where you inserted portname=$1 (the test to
see if on windows).

The $1 in the awk script is awk's own meaning of $1. Since it is
inside single quotes, the shell doesn't substitute for it.

I strongly suggest patching this before 6.5 ...

regards, tom lane

#5Thomas Lockhart
lockhart@alumni.caltech.edu
In reply to: Patrick Welche (#3)
Re: [HACKERS] regress.sh
the only remaining query being:
*** expected/random.out Sun Aug 30 19:50:58 1998
--- results/random.out  Mon Jun 14 15:18:04 1999
***************
*** 19,23 ****
WHERE random NOT BETWEEN 80 AND 120;
random
------
! (0 rows)
--- 19,24 ----
WHERE random NOT BETWEEN 80 AND 120;
random
------
!    124
! (1 row)

Well, sometimes random is too random. I'll bet if you run again you
will see a different result; I'd hope that *usually* you will see the
hoped-for result. I didn't want to make the criteria too loose so that
we would miss real problems. But sometimes the test fails, even on my
machine.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

#6Noname
wieck@debis.com
In reply to: Tom Lane (#4)
Re: [HACKERS] regress.sh

wieck@debis.com (Jan Wieck) writes:

Is it required that variables local in regress.sh have upper
case? If so, why?

Nope, you just plain broke it. The only use of the script's $1
parameter is *above* where you inserted portname=$1 (the test to
see if on windows).

Uhhhh - and there where times where I wrote awk scripts who's
output got piped into 'groff -p' to produce statistical
reports with graphics - hurts to see that I'm no real
programmer anymore :-(

The $1 in the awk script is awk's own meaning of $1. Since it is
inside single quotes, the shell doesn't substitute for it.

I strongly suggest patching this before 6.5 ...

No comment other that "sorry".

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

#7Patrick Welche
prlw1@newn.cam.ac.uk
In reply to: Thomas Lockhart (#5)
Re: [HACKERS] regress.sh

Thomas Lockhart wrote:

Well, sometimes random is too random.

?! So all is alright then :)

Cheers,

Patrick

#8Oliver Elphick
olly@lfix.co.uk
In reply to: Thomas Lockhart (#5)
Re: [HACKERS] regress.sh

Thomas Lockhart wrote:

the only remaining query being:
*** expected/random.out Sun Aug 30 19:50:58 1998
--- results/random.out  Mon Jun 14 15:18:04 1999
***************
*** 19,23 ****
WHERE random NOT BETWEEN 80 AND 120;
random
------
! (0 rows)
--- 19,24 ----
WHERE random NOT BETWEEN 80 AND 120;
random
------
!    124
! (1 row)

Well, sometimes random is too random. I'll bet if you run again you
will see a different result; I'd hope that *usually* you will see the
hoped-for result. I didn't want to make the criteria too loose so that
we would miss real problems. But sometimes the test fails, even on my
machine.

Every time I have run it I have had a 124 row. That's about 8 times.
(glibc2/linux/i386)

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"I beseech you therefore, brethren, by the mercies of
God, that ye present your bodies a living sacrifice,
holy, acceptable unto God, which is your reasonable
service." Romans 12:1

#9Noname
wieck@debis.com
In reply to: Oliver Elphick (#8)
Re: [HACKERS] regress.sh

I strongly suggest patching this before 6.5 ...

No comment other that "sorry".

Mark: Should I commit the fix on regress.sh?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #