[GEOS] #1015: Update geos-config tool for consistency

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[GEOS] #1015: Update geos-config tool for consistency

geos-2
#1015: Update geos-config tool for consistency
-----------------------------------+--------------------------
 Reporter:  robe                   |      Owner:  geos-devel@…
     Type:  defect                 |     Status:  new
 Priority:  minor                  |  Milestone:  3.9.0
Component:  Build/Install (cmake)  |    Version:  master
 Severity:  Unassigned             |   Keywords:
-----------------------------------+--------------------------
 Details repeated from https://git.osgeo.org/gitea/geos/geos/pulls/99


 ----
 **Specify bash, and use printf to escape paths (if needed)**

 This allows installation with CMake to other directories, such as `/opt/my
 prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also
 `printf` is a bash-only feature.

 **Restore bash variables, e.g. `${prefix}`, and use CMake's `@ONLY` option
 **
 Restore to prior syntax in b15fd1171823d16195bee17f2c7b44778603258d using
 `${prefix}` rather than substituting `@CMAKE_INSTALL_PREFIX@`. Re-use
 variables throughout script for convenience.

 Note that the current autotools setup does not fully install to prefixes
 that need escaping, but the CMake setup can.

 **Consistent indents and style between .in and .cmake versions**

 Use 2-space indents, re-order case statements to same order as usage. The
 Autotools and CMake versions are nearly the same, with the exception of
 Autotool's `libdir`, which perhaps could be something other than
 `$prefix/lib`?

 **Remove `exec_prefix`, which has never been used**

 Checking the history of this file, it does not seem to be used.

 **Disable configure and install for MSVC builds**

 The script requires bash, which is not used for MSVC. Scheme to install a
 MSVC version of `geos-config.bat` is drafted at [trac#1014](#1014).

 ----

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1015>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

geos-2
#1015: Update geos-config tool for consistency
-----------------------------------+---------------------------
 Reporter:  robe                   |       Owner:  geos-devel@…
     Type:  defect                 |      Status:  new
 Priority:  minor                  |   Milestone:  3.9.0
Component:  Build/Install (cmake)  |     Version:  master
 Severity:  Unassigned             |  Resolution:
 Keywords:                         |
-----------------------------------+---------------------------

Comment (by robe):

 Already committed at [4add2acf/git]

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1015#comment:1>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

geos-2
In reply to this post by geos-2
#1015: Update geos-config tool for consistency
-----------------------------------+---------------------------
 Reporter:  robe                   |       Owner:  geos-devel@…
     Type:  defect                 |      Status:  closed
 Priority:  minor                  |   Milestone:  3.9.0
Component:  Build/Install (cmake)  |     Version:  master
 Severity:  Unassigned             |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+---------------------------
Changes (by Regina Obe <lr@…>):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"9a6279fda34feb2acde8650f14f9c051e9fec60e/git"
 9a6279fd/git]:
 {{{
 #!CommitTicketReference repository="git"
 revision="9a6279fda34feb2acde8650f14f9c051e9fec60e"
 Add credits, Closes #1015
 }}}

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1015#comment:2>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
In reply to this post by geos-2
"GEOS" <[hidden email]> writes:

> #1015: Update geos-config tool for consistency
> -----------------------------------+--------------------------
>  Reporter:  robe                   |      Owner:  geos-devel@…
>      Type:  defect                 |     Status:  new
>  Priority:  minor                  |  Milestone:  3.9.0
> Component:  Build/Install (cmake)  |    Version:  master
>  Severity:  Unassigned             |   Keywords:
> -----------------------------------+--------------------------
>  Details repeated from https://git.osgeo.org/gitea/geos/geos/pulls/99
>
>
>  ----
>  **Specify bash, and use printf to escape paths (if needed)**
>
>  This allows installation with CMake to other directories, such as `/opt/my
>  prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also
>  `printf` is a bash-only feature.

It really seems like a regresssion to require bash, rather than POSIX
shell, and it's definitely a regression if the build doesn't find bash
and substitute in the path.

Is this really necessary?
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Mike Taves
On Tue, 18 Feb 2020 at 13:20, Greg Troxel <[hidden email]> wrote:

> "GEOS" <[hidden email]> writes:
> >  **Specify bash, and use printf to escape paths (if needed)**
> >
> >  This allows installation with CMake to other directories, such as `/opt/my
> >  prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also
> >  `printf` is a bash-only feature.
>
> It really seems like a regresssion to require bash, rather than POSIX
> shell, and it's definitely a regression if the build doesn't find bash
> and substitute in the path.
>
> Is this really necessary?

As noted above, the printf function is built-in with Bash, and can
properly escape a path. While I see there is also /usr/bin/printf I'm
not sure how common or standard this tool is (my tests with /bin/sh
didn't go well, so I opted to switch to Bash for reliability).
Currently, other Bash scripts are present in tools/ci/ but these are
not installed with GEOS.

Besides Native Windows, what OSes (that GEOS is used on) does not have
Bash available? As far as I know, it's available on most Linux
distributions, all recent Solaris and macOS, and even some Windows. I
can't think of any other shell that is more common.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Sandro Santilli-4
On Tue, Feb 18, 2020 at 01:55:19PM +1300, Mike Taves wrote:

> On Tue, 18 Feb 2020 at 13:20, Greg Troxel <[hidden email]> wrote:
> > "GEOS" <[hidden email]> writes:
> > >  **Specify bash, and use printf to escape paths (if needed)**
> > >
> > >  This allows installation with CMake to other directories, such as `/opt/my
> > >  prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also
> > >  `printf` is a bash-only feature.
> >
> > It really seems like a regresssion to require bash, rather than POSIX
> > shell, and it's definitely a regression if the build doesn't find bash
> > and substitute in the path.
> >
> > Is this really necessary?
>
> As noted above, the printf function is built-in with Bash, and can
> properly escape a path. While I see there is also /usr/bin/printf I'm
> not sure how common or standard this tool is (my tests with /bin/sh
> didn't go well, so I opted to switch to Bash for reliability).

GNU coreutils "printf" works fine here:

  [strk@liz:~] /usr/bin/printf "%q\n" "space 'quote' and \"doublequote\""
  'space '\''quote'\'' and "doublequote"'
  [strk@liz:~] /usr/bin/printf  --version | head -1
  printf (GNU coreutils) 8.28

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Mike Taves
On Tue, 18 Feb 2020 at 20:22, Sandro Santilli <[hidden email]> wrote:

> > properly escape a path. While I see there is also /usr/bin/printf I'm
> > not sure how common or standard this tool is (my tests with /bin/sh
> > didn't go well, so I opted to switch to Bash for reliability).
>
> GNU coreutils "printf" works fine here:
>
>   [strk@liz:~] /usr/bin/printf "%q\n" "space 'quote' and \"doublequote\""
>   'space '\''quote'\'' and "doublequote"'
>   [strk@liz:~] /usr/bin/printf  --version | head -1
>   printf (GNU coreutils) 8.28

The printf function in Bash has supported the %q directive for much longer
https://stackoverflow.com/a/26069697
https://web.archive.org/web/20031119043100/http://www.gnu.org/software/bash/manual/bashref.html

whereas the %q directive for /usr/bin/printf was introduced a few
years ago, and seems to produce a different output, for example having
a single quotation mark on either end of the above example. Bash's
printf does not add single quotation marks to the output, as it is in
a format that can be reused as shell input.

In short: I can't easily get the same escaped output using #!/bin/sh
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
In reply to this post by Mike Taves
Mike Taves <[hidden email]> writes:

> On Tue, 18 Feb 2020 at 13:20, Greg Troxel <[hidden email]> wrote:
>> "GEOS" <[hidden email]> writes:
>> >  **Specify bash, and use printf to escape paths (if needed)**
>> >
>> >  This allows installation with CMake to other directories, such as `/opt/my
>> >  prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also
>> >  `printf` is a bash-only feature.
>>
>> It really seems like a regresssion to require bash, rather than POSIX
>> shell, and it's definitely a regression if the build doesn't find bash
>> and substitute in the path.
>>
>> Is this really necessary?
>
> As noted above, the printf function is built-in with Bash, and can
> properly escape a path. While I see there is also /usr/bin/printf I'm
> not sure how common or standard this tool is (my tests with /bin/sh
> didn't go well, so I opted to switch to Bash for reliability).

First, to me requiring bash is worse than telling people not to do
ridiculous things like putting spaces in pathnames :-)  But I realize
other people think spaces in pathnames is an ok thing.

The right question about tools is not what's typically on Linux but what
POSIX requires.

In searching for the POSIX printf spec, I found this post about escaping
spaces in a portable manner.

  https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q

The specs at opengroup.org seem hard to deal with today - not sure if
they changed - but I found this POSIX printf description:

  https://www.unix.com/man-page/POSIX/1posix/printf/

> Currently, other Bash scripts are present in tools/ci/ but these are
> not installed with GEOS.

ci tools are quite a different story than a requirement for regular
installs, although I see using bash there (vs /bin/sh) as a bug also.

> Besides Native Windows, what OSes (that GEOS is used on) does not have
> Bash available? As far as I know, it's available on most Linux
> distributions, all recent Solaris and macOS, and even some Windows. I
> can't think of any other shell that is more common.

The shell that is more common is the one required by POSIX: /bin/sh,
having the behavior specified by POSIX.   Bash either conforms to POSIX
or is close enough, so code written for POSIX will work fine with bash.  

None of the BSDs have bash by default.  When it is present, via ports,
pkgsrc, etc., it's not in /bin.  On NetBSD, it's in /usr/pkg/bin/bash.
People use it for their login shell.  I do too - I'm not a bash hater,
but object to it for programming use.  It's enormous, and is one
particular implementation among many.  I view it as personal choice to
use it for interactive use, and not appropriate for scripting.

The fact that /bin/bash does not exist on *BSD, and probably other
places, prompted my question about looking for it and substituting the
path.  Expecting bash to be in /bin/bash is just not a valid assumption.


So, given that there seems to be a way to do this without introducing a
dependenchy on bash, I'd like to see this backed out.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Paul Ramsey


> On Feb 18, 2020, at 6:11 AM, Greg Troxel <[hidden email]> wrote:
>
> Mike Taves <[hidden email]> writes:
>
>> On Tue, 18 Feb 2020 at 13:20, Greg Troxel <[hidden email]> wrote:
>>> "GEOS" <[hidden email]> writes:
>>>> **Specify bash, and use printf to escape paths (if needed)**
>>>>
>>>> This allows installation with CMake to other directories, such as `/opt/my
>>>> prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also
>>>> `printf` is a bash-only feature.
>>>
>>> It really seems like a regression to require bash, rather than POSIX
>>> shell, and it's definitely a regression if the build doesn't find bash
>>> and substitute in the path.
>>>
>>> Is this really necessary?
>>
>> As noted above, the printf function is built-in with Bash, and can
>> properly escape a path. While I see there is also /usr/bin/printf I'm
>> not sure how common or standard this tool is (my tests with /bin/sh
>> didn't go well, so I opted to switch to Bash for reliability).
>
> First, to me requiring bash is worse than telling people not to do
> ridiculous things like putting spaces in pathnames :-)  But I realize
> other people think spaces in pathnames is an ok thing.
>
> The right question about tools is not what's typically on Linux but what
> POSIX requires.
>
> In searching for the POSIX printf spec, I found this post about escaping
> spaces in a portable manner.
>
>  https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q
>
> The specs at opengroup.org seem hard to deal with today - not sure if
> they changed - but I found this POSIX printf description:
>
>  https://www.unix.com/man-page/POSIX/1posix/printf/
>
>> Currently, other Bash scripts are present in tools/chi/ but these are
>> not installed with GEOS.
>
> chi tools are quite a different story than a requirement for regular
> installs, although I see using bash there (vs /bin/sh) as a bug also.
>
>> Besides Native Windows, what OSes (that GEOS is used on) does not have
>> Bash available? As far as I know, it's available on most Linux
>> distributions, all recent Solaris and macOS, and even some Windows. I
>> can't think of any other shell that is more common.
>
> The shell that is more common is the one required by POSIX: /bin/sh,
> having the behaviour specified by POSIX.   Bash either conforms to POSIX
> or is close enough, so code written for POSIX will work fine with bash.  
>
> None of the BSDs have bash by default.  When it is present, via ports,
> pkgsrc, etc., it's not in /bin.  On NetBSD, it's in /usr/pkg/bin/bash.
> People use it for their login shell.  I do too - I'm not a bash hater,
> but object to it for programming use.  It's enormous, and is one
> particular implementation among many.  I view it as personal choice to
> use it for interactive use, and not appropriate for scripting.
>
> The fact that /bin/bash does not exist on *BSD, and probably other
> places, prompted my question about looking for it and substituting the
> path.  Expecting bash to be in /bin/bash is just not a valid assumption.

Yeah, and with Apple changing the default shell in OSX, this only gets worse not better over time…
Could follow the pgsql project and just rewrite the thing (the config program) in C and be done with it…
P

>
>
> So, given that there seems to be a way to do this without introducing a
> dependenchy on bash, I'd like to see this backed out.
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
Paul Ramsey <[hidden email]> writes:

> Yeah, and with Apple changing the default shell in OSX, this only gets worse not better over time…
> Could follow the pgsql project and just rewrite the thing (the config program) in C and be done with it…

Or, perhaps generate a pkgconfig file and just get rid of geos-config?
There is some one-time pain, but it seems that hand-written foo-config
is no longer the preferred approach.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Paul Ramsey
Pkg config is wonderous but still far from universal

> On Feb 18, 2020, at 10:14 AM, Greg Troxel <[hidden email]> wrote:
>
> Paul Ramsey <[hidden email]> writes:
>
>> Yeah, and with Apple changing the default shell in OSX, this only gets worse not better over time…
>> Could follow the pgsql project and just rewrite the thing (the config program) in C and be done with it…
>
> Or, perhaps generate a pkgconfig file and just get rid of geos-config?
> There is some one-time pain, but it seems that hand-written foo-config
> is no longer the preferred approach.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
Paul Ramsey <[hidden email]> writes:

> Pkg config is wonderous but still far from universal

Interesting.  As a packager, I see a vast number of things using it, and
thus a system where it isn't available as a build dependency would seem
very difficult to deal with in general.  I would not have suggested it
if I thought anyplace would have trouble with that (except that I don't
pay attention to Windows at all).

On my desktop there are 557 .pc files installed from pkgsrc, 9 from the
base system, and 127 from pkgsrc.  Geo-examples include proj, gdal and
spatialite.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Regina Obe
> Paul Ramsey <[hidden email]> writes:
>
> > Pkg config is wonderous but still far from universal
>
> Greg Troxel  writes:
> Interesting.  As a packager, I see a vast number of things using it, and thus a
> system where it isn't available as a build dependency would seem very
> difficult to deal with in general.  I would not have suggested it if I thought
> anyplace would have trouble with that (except that I don't pay attention to
> Windows at all).
>
> On my desktop there are 557 .pc files installed from pkgsrc, 9 from the base
> system, and 127 from pkgsrc.  Geo-examples include proj, gdal and spatialite.
>

I think on visual studio pkg is kinda supported but not out of the box.  Someone who uses VS can confirm that.
Can CMake always use pkg or is it even relevant since CMake we have a separate chain?  For Windows build, we require CMake now anyway -- so it would then be a "If CMake supports it on windows we can do it"?

On mingw/msys2 which I use for windows building -  pkg-config is well supported. So fine with me.

That said even if we did go down the path of pkgsrc I think we need to support geos-config for a couple of minor versions to give libraries that depend on GEOS time to change.
For example PostGIS expects a geos-config file.  So we'd have to change all supported versions to allow .pc for geos.

Or am I missing something here?

Speaking of reverting the last change that started this whole discussion -- does anyone have thoughts on alternative to printf for sh?
I would like to keep the intent if possible without causing backward compatibility issues.

I assume these are the sections that would need reverting.

https://git.osgeo.org/gitea/geos/geos/pulls/99.diff  - in the tools/geos-config.cmake #!/bin/sh

index 24a5725..abef1e3 100644
--- a/tools/geos-config.cmake
+++ b/tools/geos-config.cmake
@@ -1,12 +1,12 @@
-#!/bin/sh
+#!/bin/bash -e
 
-prefix=@CMAKE_INSTALL_PREFIX@
-exec_prefix=@CMAKE_INSTALL_PREFIX@/bin
-libdir=@CMAKE_INSTALL_PREFIX@/lib
+# escape path
+prefix=$(printf %q "@CMAKE_INSTALL_PREFIX@")
+libdir=${prefix}/lib

and tools/geos-config.in

--- a/tools/geos-config.in
+++ b/tools/geos-config.in
@@ -1,11 +1,12 @@
-#!/bin/sh
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
+#!/bin/bash -e
+
+# escape paths
+prefix=$(printf %q "@prefix@")
+libdir=$(printf %q "@libdir@")


Thanks,
Regina






_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Mike Taves
In reply to this post by Greg Troxel-2
On Wed, 19 Feb 2020 at 03:11, Greg Troxel <[hidden email]> wrote:

> First, to me requiring bash is worse than telling people not to do
> ridiculous things like putting spaces in pathnames :-)  But I realize
> other people think spaces in pathnames is an ok thing.
>
> The right question about tools is not what's typically on Linux but what
> POSIX requires.
>
> In searching for the POSIX printf spec, I found this post about escaping
> spaces in a portable manner.
>
>   https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q
>
> The specs at opengroup.org seem hard to deal with today - not sure if
> they changed - but I found this POSIX printf description:
>
>   https://www.unix.com/man-page/POSIX/1posix/printf/

Thanks for the resources!

> > Currently, other Bash scripts are present in tools/ci/ but these are
> > not installed with GEOS.
>
> ci tools are quite a different story than a requirement for regular
> installs, although I see using bash there (vs /bin/sh) as a bug also.

I'll consider going over these to see if they can be POSIX /bin/sh

> > Besides Native Windows, what OSes (that GEOS is used on) does not have
> > Bash available?
>
> None of the BSDs have bash by default.  When it is present, via ports,
> pkgsrc, etc., it's not in /bin.  On NetBSD, it's in /usr/pkg/bin/bash.
> People use it for their login shell.  I do too - I'm not a bash hater,
> but object to it for programming use.  It's enormous, and is one
> particular implementation among many.  I view it as personal choice to
> use it for interactive use, and not appropriate for scripting.
>
> The fact that /bin/bash does not exist on *BSD, and probably other
> places, prompted my question about looking for it and substituting the
> path.  Expecting bash to be in /bin/bash is just not a valid assumption.
>
> So, given that there seems to be a way to do this without introducing a
> dependenchy on bash, I'd like to see this backed out.

Aha, so there are some that will be alienated, which I agree is a bad
situation, so I'll submit a PR to restore back to #!/bin/sh

I'll remove printf %q altogether and simply insert an escaped path to
the script. I'll probably only do this with CMake, since that's the
only install solution that supports spaces.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
In reply to this post by Regina Obe
This seems to explain how to accomodate spaces in pathnames and escaping
them, sticking to POSIX

  https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q

cmake is very much set up to use pkg-config; it has become the normal
way by which build systems query how to link to dependency packages.  I
don't think it has anything to do with Visual Studio in a cmake build.
I don't know anything about cmake on windows, but it doesn't make sense
that this would be trouble since it is so pervasive.  But I could be off.

  That said even if we did go down the path of pkgsrc I think we need to
  support geos-config for a couple of minor versions to give libraries
  that depend on GEOS time to change.  For example PostGIS expects a
  geos-config file.  So we'd have to change all supported versions to
  allow .pc for geos.

(pkg-config not pkgsrc, assuming word-o).  Yes, would need some compat
and switchover.  Many programs have moved from foo-config to a .pc over
the years.  On my system I have only 65 foo-config programs, compared to
to 557 pkgconfig files (both in /usr/pkg, so that is an apples to apples
comparison).

I am pretty sure there is an idiom which looks like

  try to find geos via pc
  if not, try geos-config

at least in autoconf that was a fairly normal thing to do for a while.

I will observe that a strategy of:

   add pkgconfig more or less now

   decline to worry about spaces in prefix in geos-config (tell people
   that want to put spaces in pathnames that to use pkgconfig ;-)

seems reasonable to me.   But I have no objection to accomodating spaces
if it doesn't add a bash or other dependency.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
In reply to this post by Regina Obe
"Regina Obe" <[hidden email]> writes:

> Speaking of reverting the last change that started this whole
> discussion -- does anyone have thoughts on alternative to printf for
> sh?  I would like to keep the intent if possible without causing
> backward compatibility issues.
>
> I assume these are the sections that would need reverting.
>
> https://git.osgeo.org/gitea/geos/geos/pulls/99.diff  - in the tools/geos-config.cmake #!/bin/sh
>
> index 24a5725..abef1e3 100644
> --- a/tools/geos-config.cmake
> +++ b/tools/geos-config.cmake
> @@ -1,12 +1,12 @@
> -#!/bin/sh
> +#!/bin/bash -e
>  
> -prefix=@CMAKE_INSTALL_PREFIX@
> -exec_prefix=@CMAKE_INSTALL_PREFIX@/bin
> -libdir=@CMAKE_INSTALL_PREFIX@/lib
> +# escape path
> +prefix=$(printf %q "@CMAKE_INSTALL_PREFIX@")
> +libdir=${prefix}/lib
>
> and tools/geos-config.in
>
> --- a/tools/geos-config.in
> +++ b/tools/geos-config.in
> @@ -1,11 +1,12 @@
> -#!/bin/sh
> -prefix=@prefix@
> -exec_prefix=@exec_prefix@
> -libdir=@libdir@
> +#!/bin/bash -e
> +
> +# escape paths
> +prefix=$(printf %q "@prefix@")
> +libdir=$(printf %q "@libdir@")

So assigning

prefix=@prefix@

works perfectly fine.  The problem is when that is printed later.

If it's just space we are worried about, one could basically printf into
sed to change space to "\ ", and I think that's what the stack overflow
suggestion is doing.

The basic problem is that the build ecosystems assume that one can use
space to tokenize arguments.  That is indeed the ancient Unix tradition,
and fighting that leads to lots of pain with quoting.

There's another problem here, which is that inserting \ for quoting is
presuming that the output of geos-config is going to be interpreted by a
shell, rather than taken as is and used to build a command line.  I
suppose there is that implication because there are multiiple arguments
separated by a space.  One could argue that the interface is space
separated arguments, not shell language.  So overall I see allowing
spaces in prefix as heading off into not-well-defined behavior.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Greg Troxel-2
In reply to this post by Mike Taves
Mike Taves <[hidden email]> writes:

> On Wed, 19 Feb 2020 at 03:11, Greg Troxel <[hidden email]> wrote:
>> In searching for the POSIX printf spec, I found this post about escaping
>> spaces in a portable manner.
>>
>>   https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q
>>
>> The specs at opengroup.org seem hard to deal with today - not sure if
>> they changed - but I found this POSIX printf description:
>>
>>   https://www.unix.com/man-page/POSIX/1posix/printf/
>
> Thanks for the resources!

Thank you for listening (seriously).  We are, amusingly enough, moving
to a point where there is an assumption of all linux, much like the old
days when it was assumed all was windows.

>> > Currently, other Bash scripts are present in tools/ci/ but these are
>> > not installed with GEOS.
>>
>> ci tools are quite a different story than a requirement for regular
>> installs, although I see using bash there (vs /bin/sh) as a bug also.
>
> I'll consider going over these to see if they can be POSIX /bin/sh

Thanks - I don't think that's nearly as big a deal, but in my experience
dealing with packaging I have found that many uses of bash were not
actually necessary or very easy to avoid.  One common issue is using ==
in test, when POSIX specifies (and Bourne shells always were) just =.

>> None of the BSDs have bash by default.  When it is present, via ports,
>> pkgsrc, etc., it's not in /bin.  On NetBSD, it's in /usr/pkg/bin/bash.
>> People use it for their login shell.  I do too - I'm not a bash hater,
>> but object to it for programming use.  It's enormous, and is one
>> particular implementation among many.  I view it as personal choice to
>> use it for interactive use, and not appropriate for scripting.
>>
>> The fact that /bin/bash does not exist on *BSD, and probably other
>> places, prompted my question about looking for it and substituting the
>> path.  Expecting bash to be in /bin/bash is just not a valid assumption.
>>
>> So, given that there seems to be a way to do this without introducing a
>> dependenchy on bash, I'd like to see this backed out.
>
> Aha, so there are some that will be alienated, which I agree is a bad
> situation, so I'll submit a PR to restore back to #!/bin/sh

Great, thanks.

> I'll remove printf %q altogether and simply insert an escaped path to
> the script. I'll probably only do this with CMake, since that's the
> only install solution that supports spaces.

I didn't realize autoconf flat-out objected to spaces, but it is not
surprising since in the old-school command line tradition spaces is
files are somewhere between bizarre and unthinkable.

Sounds good to just escape spaces for cmake.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Mike Taves
On Wed, 19 Feb 2020 at 09:28, Greg Troxel <[hidden email]> wrote:
> > Aha, so there are some that will be alienated, which I agree is a bad
> > situation, so I'll submit a PR to restore back to #!/bin/sh
>
> Great, thanks.

See/review https://git.osgeo.org/gitea/geos/geos/pulls/100

however, this only considers escaping spaces for CMake's install. I'm
less familiar on how Autotools could preprocess a similar escaped
version with sed, but as I mentioned previously other fixes would be
required to get Autotools to support prefixes with spaces.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Mike Taves
In reply to this post by Greg Troxel-2
On Wed, 19 Feb 2020 at 09:28, Greg Troxel <[hidden email]> wrote:

> >> > Currently, other Bash scripts are present in tools/ci/ but these are
> >> > not installed with GEOS.
> >>
> >> ci tools are quite a different story than a requirement for regular
> >> installs, although I see using bash there (vs /bin/sh) as a bug also.
> >
> > I'll consider going over these to see if they can be POSIX /bin/sh
>
> Thanks - I don't think that's nearly as big a deal, but in my experience
> dealing with packaging I have found that many uses of bash were not
> actually necessary or very easy to avoid.  One common issue is using ==
> in test, when POSIX specifies (and Bourne shells always were) just =.

See also https://git.osgeo.org/gitea/geos/geos/pulls/101
which is low priority, considering that I'm certain that most
environment that use /tools/ci have Bash, and script_cmake.sh has an
external dependency on Bash to call https://codecov.io/bash which
cannot be avoided.
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1015: Update geos-config tool for consistency

Sandro Santilli-4
In reply to this post by Mike Taves
On Tue, Feb 18, 2020 at 10:16:38PM +1300, Mike Taves wrote:

> On Tue, 18 Feb 2020 at 20:22, Sandro Santilli <[hidden email]> wrote:
> > > properly escape a path. While I see there is also /usr/bin/printf I'm
> > > not sure how common or standard this tool is (my tests with /bin/sh
> > > didn't go well, so I opted to switch to Bash for reliability).
> >
> > GNU coreutils "printf" works fine here:
> >
> >   [strk@liz:~] /usr/bin/printf "%q\n" "space 'quote' and \"doublequote\""
> >   'space '\''quote'\'' and "doublequote"'
> >   [strk@liz:~] /usr/bin/printf  --version | head -1
> >   printf (GNU coreutils) 8.28
>
> The printf function in Bash has supported the %q directive for much longer
> https://stackoverflow.com/a/26069697
> https://web.archive.org/web/20031119043100/http://www.gnu.org/software/bash/manual/bashref.html
>
> whereas the %q directive for /usr/bin/printf was introduced a few
> years ago, and seems to produce a different output, for example having
> a single quotation mark on either end of the above example. Bash's
> printf does not add single quotation marks to the output, as it is in
> a format that can be reused as shell input.

Do you have a use case for avoiding the single quotation mark from the
output of geos-config ?

Few-years-ago dependency could be fine, given GEOS requires C++10 now,
or we could just use quotes and allow for spaces in path names (while
still forbidding quotes and dollars etc. ?)

Do you have examples of paths you need to support ?

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
12