[Slackbuilds-users] hoorex-0.6.4 and tty control Strings

[Konrad J Hambrick]

Chris --

I've been using hoorex in several scripts to generate build / install lists
for SBo Programs.

This week's hoorex version 0.6.4 broke my SBo Update scripts.

Specifically, it is the newly introduced, ANSI termcap / terminfo strings
in the # OUTPUT section ( lines 284- 304 ) that cause issues.

Since the only changes between 0.6.2 and 0.6.4 are the license and the ANSI
Terminal Strings, I have reverted to hoorex 0.6.2

Would it be possible to turn off the ANSI terminfo strings by command line
argument or by default or via the config file or even better, if the output
device is not an ANSI tty ?

One other suggestion for portability is to check out the python curses
module rather than hard-coding VT100 Escape Sequences ?

Anyhow, that doesn't matter today as much as it did in the olden days (
nobody runs Wyse60 or Techtronics Terninals anymore :)

Thanks for hoorex Chris. I couldn't keep up with SBo without it !
-- kjh

[Christoph Willing]

Post by Konrad J Hambrick
Chris --
I've been using hoorex in several scripts to generate build / install
lists for SBo Programs.
This week's hoorex version 0.6.4 broke my SBo Update scripts.
Specifically, it is the newly introduced, ANSI termcap /  terminfo
strings in the # OUTPUT section ( lines 284- 304 ) that cause issues.
Since the only changes between 0.6.2 and 0.6.4 are the license and the
ANSI Terminal Strings, I have reverted to hoorex 0.6.2
Would it be possible to turn off the ANSI terminfo strings by command
line argument or by default or via the config file or even better, if
the output device is not an ANSI tty ?

Sorry about that. I had considered controlling it with a command line
option but after I wondered about the possibility of encountering
non-ANSI terminals for nearly 5 minutes, I didn't bother with it. What
could go wrong?

Post by Konrad J Hambrick
One other suggestion for portability is to check out the python curses
module rather than hard-coding VT100 Escape Sequences ?

I had also looked at that possibility - the seemingly magical detection
of terminal type was really attractive but it looked pretty awkward to
set up programmatically. After looking at it again since you've raised
this problem, I think I may have found a relatively simple way to
implement a solution.

A problem I will have with the python curses solution is how to test. Is
your problem due to a physical device you're using, or is it to do with
how you're using hoorex in your update scripts i.e. something I could
replicate sufficiently to test any fix?

chris











_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ

[Christoph Willing]

[snip]

Post by Christoph Willing
A problem I will have with the python curses solution is how to test. Is
your problem due to a physical device you're using, or is it to do with
how you're using hoorex in your update scripts i.e. something I could
replicate sufficiently to test any fix?

Hi Konrad,

I just discovered something which I hope is relevant - I can see the
escape sequences when I pipe or redirect hoorex output anywhere. That
breaks a use case described in the man page - not good - so I've
committed a fix for this situation (by first testing whether output
device is a tty).

Is your case similar to that (a script piping or redirecting hoorex
output somewhere)? If so, the attached patch should fix it. Could you
test it (against 0.6.4) if you have time?

Thanks,
chris

[Konrad J Hambrick]

On Mon, Sep 17, 2018 at 12:46 AM, Christoph Willing <

Post by Christoph Willing
[snip]

Post by Christoph Willing
A problem I will have with the python curses solution is how to test. Is
your problem due to a physical device you're using, or is it to do with
how you're using hoorex in your update scripts i.e. something I could
replicate sufficiently to test any fix?

Hi Konrad,
I just discovered something which I hope is relevant - I can see the
escape sequences when I pipe or redirect hoorex output anywhere. That
breaks a use case described in the man page - not good - so I've
committed a fix for this situation (by first testing whether output
device is a tty).
Is your case similar to that (a script piping or redirecting hoorex
output somewhere)? If so, the attached patch should fix it. Could you
test it (against 0.6.4) if you have time?
Thanks,
chris
Chris --

Yes, I am invoking something like the code below my sig.

-- kjh

Example: what do I need for postgis ?

### cut here ###
Pkg="postgis"
Lst=""

for Dep in $(hoorex -r -m $Pkg)
do

GotIt="$(ls -1 /var/log/packages/$Dep-[0-9]* 2>/dev/null)"

if [ "$GotIt" != "" ]
then
echo "$Dep is already installed as $(basename $GotIt)"
continue
fi

Lst="$Lst $Dep"

echo "you'll need to build and install $Dep"

# sh get-SBo-pkg $Dep # this script copies the SBo Directory to my
working Directory and downloads files and checks md5sums

done

[ "$Lst" != "" ] && echo "now go build and intstall $Lst"

### cut there ###

This is what I see today for postgis:

geos is already installed as geos-3.7.0-x86_64-1_SBo
proj is already installed as proj-5.1.0-x86_64-2_SBo
postgresql is already installed as postgresql-9.6.10-x86_64-1_SBo_kjh
gdal is already installed as gdal-2.3.1-x86_64-1_SBo_kjh
postgis is already installed as postgis-2.4.5-x86_64-1_SBo

[Christoph Willing]

Post by Konrad J Hambrick
On Mon, Sep 17, 2018 at 12:46 AM, Christoph Willing
[snip]

Post by Christoph Willing
A problem I will have with the python curses solution is how to test. Is
your problem due to a physical device you're using, or is it to do with
how you're using hoorex in your update scripts i.e. something I could
replicate sufficiently to test any fix?

Hi Konrad,
I just discovered something which I hope is relevant - I can see the
escape sequences when I pipe or redirect hoorex output anywhere. That
breaks a use case described in the man page - not good - so I've
committed a fix for this situation (by first testing whether output
device is a tty).
Is your case similar to that (a script piping or redirecting hoorex
output somewhere)? If so, the attached patch should fix it. Could you
test it (against 0.6.4) if you have time?
Thanks,
chris
Chris --
Yes, I am invoking something like the code below my sig.

Thanks Konrad,

I've confirmed that your sample code works correctly with the fix I made
to hoorex. That fix is included in hoorex-0.6.5, for which I've pushed
an updated SlackBuild to SBo, so should be available in next round of
updates at the weekend. If you're in a hurry, it's also available now at:

https://git.slackbuilds.org/slackbuilds/tree/misc/hoorex?h=user/chris.willing/updates
although, for your use case, there's no particular advantage over v0.6.2
that you reverted to.

chris

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-***@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Konrad J Hambrick]

On Mon, Sep 17, 2018 at 7:06 PM, Christoph Willing <

Post by Christoph Willing

Post by Konrad J Hambrick
On Mon, Sep 17, 2018 at 12:46 AM, Christoph Willing
[snip]

Post by Christoph Willing
A problem I will have with the python curses solution is how to

test. Is

Post by Konrad J Hambrick

Post by Christoph Willing
your problem due to a physical device you're using, or is it to do

with

Post by Konrad J Hambrick

Post by Christoph Willing
how you're using hoorex in your update scripts i.e. something I

could

Post by Konrad J Hambrick

Post by Christoph Willing
replicate sufficiently to test any fix?

Hi Konrad,
I just discovered something which I hope is relevant - I can see the
escape sequences when I pipe or redirect hoorex output anywhere. That
breaks a use case described in the man page - not good - so I've
committed a fix for this situation (by first testing whether output
device is a tty).
Is your case similar to that (a script piping or redirecting hoorex
output somewhere)? If so, the attached patch should fix it. Could you
test it (against 0.6.4) if you have time?
Thanks,
chris
Chris --
Yes, I am invoking something like the code below my sig.

Thanks Konrad,
I've confirmed that your sample code works correctly with the fix I made
to hoorex. That fix is included in hoorex-0.6.5, for which I've pushed
an updated SlackBuild to SBo, so should be available in next round of
https://git.slackbuilds.org/slackbuilds/tree/misc/hoorex?
h=user/chris.willing/updates
although, for your use case, there's no particular advantage over v0.6.2
that you reverted to.

Thanks Chris

It'll be nice to have hoorex off my ever-growing weekly `.find-SB-updates`
listing :)

It is one of the SBo Packages that I always update first :)

Thank a ton for hoorex !

-- kjh
# ./.find-SB-updates

# AppName |OldVer |NewVer |Installed
PkgFile
arp-scan |1.9.2 |1.9
|arp-scan-1.9.2-x86_64-1_SBo
psqlodbc |10.3.0 |10.2.0
|psqlodbc-10.3.0-x86_64-1_SBo_kjh
CGAL |4.11.1 |4.12.1
|CGAL-4.11.1-x86_64-1_SBo_kjh_B80529_test
hdf5 |1.8.17 |1.8.15_patch1
|hdf5-1.8.17-x86_64-1_SBo
rabbitmq-server |3.7.7 |3.6.10
|rabbitmq-server-3.7.7-x86_64-1_SBo_kjh
intel-microcode |20180807a |20180807
|intel-microcode-20180807a-noarch-1_SBo_kjh
postgresql |9.6.10 |10.2
|postgresql-9.6.10-x86_64-1_SBo_kjh
hoorex |0.6.2 |0.6.4
|hoorex-0.6.2-noarch-1_SBo
adobe-reader |9.5.5_enu |9.5.5
|adobe-reader-9.5.5_enu-i486-1_SBo
gdal |2.3.1 |2.2.4
|gdal-2.3.1-x86_64-1_SBo_kjh
opencl-headers |2.2 |1.1
|opencl-headers-2.2-noarch-1_SBo

[Konrad J Hambrick]

Post by Konrad J Hambrick
On Mon, Sep 17, 2018 at 7:06 PM, Christoph Willing <

Post by Christoph Willing

Post by Konrad J Hambrick
On Mon, Sep 17, 2018 at 12:46 AM, Christoph Willing
[snip]

Post by Christoph Willing
A problem I will have with the python curses solution is how to

test. Is

Post by Konrad J Hambrick

Post by Christoph Willing
your problem due to a physical device you're using, or is it to

do with

Post by Konrad J Hambrick

Post by Christoph Willing
how you're using hoorex in your update scripts i.e. something I

could

Post by Konrad J Hambrick

Post by Christoph Willing
replicate sufficiently to test any fix?

Hi Konrad,
I just discovered something which I hope is relevant - I can see the
escape sequences when I pipe or redirect hoorex output anywhere.

That

Post by Konrad J Hambrick
breaks a use case described in the man page - not good - so I've
committed a fix for this situation (by first testing whether output
device is a tty).
Is your case similar to that (a script piping or redirecting hoorex
output somewhere)? If so, the attached patch should fix it. Could

you

Post by Konrad J Hambrick
test it (against 0.6.4) if you have time?
Thanks,
chris
Chris --
Yes, I am invoking something like the code below my sig.

Thanks Konrad,
I've confirmed that your sample code works correctly with the fix I made
to hoorex. That fix is included in hoorex-0.6.5, for which I've pushed
an updated SlackBuild to SBo, so should be available in next round of
https://git.slackbuilds.org/slackbuilds/tree/misc/hoorex?h=
user/chris.willing/updates
although, for your use case, there's no particular advantage over v0.6.2
that you reverted to.

Thanks Chris
It'll be nice to have hoorex off my ever-growing weekly `.find-SB-updates`
listing :)
It is one of the SBo Packages that I always update first :)
Thank a ton for hoorex !
-- kjh
# ./.find-SB-updates
# AppName |OldVer |NewVer |Installed
PkgFile
arp-scan |1.9.2 |1.9
|arp-scan-1.9.2-x86_64-1_SBo
psqlodbc |10.3.0 |10.2.0
|psqlodbc-10.3.0-x86_64-1_SBo_kjh
CGAL |4.11.1 |4.12.1
|CGAL-4.11.1-x86_64-1_SBo_kjh_B80529_test
hdf5 |1.8.17 |1.8.15_patch1
|hdf5-1.8.17-x86_64-1_SBo
rabbitmq-server |3.7.7 |3.6.10
|rabbitmq-server-3.7.7-x86_64-1_SBo_kjh
intel-microcode |20180807a |20180807
|intel-microcode-20180807a-noarch-1_SBo_kjh
postgresql |9.6.10 |10.2
|postgresql-9.6.10-x86_64-1_SBo_kjh
hoorex |0.6.2 |0.6.4
|hoorex-0.6.2-noarch-1_SBo
adobe-reader |9.5.5_enu |9.5.5
|adobe-reader-9.5.5_enu-i486-1_SBo
gdal |2.3.1 |2.2.4
|gdal-2.3.1-x86_64-1_SBo_kjh
opencl-headers |2.2 |1.1
|opencl-headers-2.2-noarch-1_SBo

Thank you Chris !

hoorex version 0.6.5 works great in my scripts !

Simple Test Script:

# for i in `hoorex -r gdal` ; do echo -e "$i\c" |hd -h ; done

00000000 67 65 6f 73 geos
00000000 70 72 6f 6a proj
00000000 67 64 61 6c gdal

No more pesky 0x1b char strings now :)

Thanks again !!

-- kjh

This is the /home/local/bin/hd script from the test script:

[cut here]-------------------------------------------------------
#!/bin/sh

PrgNam=`basename $0`
DirNam=`dirname $0`
Flags=""
Head=1

if [ "$1" = "-v" ]
then
Flags="-v"
shift
fi
if [ "$1" = "-h" ]
then
Head="0"
shift
fi

if [ "$Head" != "0" ]
then
echo "# Offset 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F Text"
echo "# ====== == == == == == == == == == == == == == == == ==
================"
fi

if [ $# -gt 0 ]
then
hexdump $Flags -f ${DirNam}/${PrgNam}.fmt "$@" 2>/dev/null
else
hexdump $Flags -f ${DirNam}/${PrgNam}.fmt 2>/dev/null
fi 2>/dev/null
[cut there]-------------------------------------------------------