Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.os2.programmer.misc > #1434 > unrolled thread

Change of string parsing in libc066

Back to article view | Back to comp.os.os2.programmer.misc

Contents

  Change of string parsing in libc066 James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-11-03 11:18 -0700
    Re: Change of string parsing in libc066 KO Myung-Hun <komh@chollian.net> - 2014-11-04 14:50 +0900
      Re: Change of string parsing in libc066 James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-11-03 23:44 -0700
        Re: Change of string parsing in libc066 "A.D. Fundum" <what.ever@neverm.ind> - 2014-11-04 13:14 +0100
        Re: Change of string parsing in libc066 KO Myung-Hun <komh@chollian.net> - 2014-11-05 00:43 +0900
      Re: Change of string parsing in libc066 James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-11-04 10:28 -0700
        Re: Change of string parsing in libc066 "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-11-04 18:58 +0000
          Re: Change of string parsing in libc066 James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-11-04 14:14 -0700
        Re: Change of string parsing in libc066 KO Myung-Hun <komh@chollian.net> - 2014-11-05 10:03 +0900
      Re: Change of string parsing in libc066 James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-11-05 18:09 -0700
        Re: Change of string parsing in libc066 KO Myung-Hun <komh@chollian.net> - 2014-11-06 13:05 +0900
        Re: Change of string parsing in libc066 James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-11-06 13:37 -0700
        Re: Change of string parsing in libc066 Dave Yeo <dave.r.yeo@gmail.com> - 2014-11-06 20:35 -0800

#1434 — Change of string parsing in libc066

Hello,
  I installed libc066.dll and its supporting referrers. It has broken
important parts of PMMail, and, I suspect, other programs.
  In particular lib functions like system() and remove() process the
input string differently. Previously, a string like

D:\usr\bin\gpg.exe --version 1> gpg.ver

was passed through unchanged. Now it becomes

D:usrbingpg.exe --version 1> gpg.ver

  Obviously a problem. I could, of course, write wrappers for all of
those lib functions affected, but why should I?
  Is the modified parsing intentional?

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [next] | [standalone]

#1435

Hi/2.

James Moe wrote:
> 
> Hello,
>   I installed libc066.dll and its supporting referrers. It has broken
> important parts of PMMail, and, I suspect, other programs.
>   In particular lib functions like system() and remove() process the
> input string differently. Previously, a string like
> 
> D:\usr\bin\gpg.exe --version 1> gpg.ver
> 
> was passed through unchanged. Now it becomes
> 
> D:usrbingpg.exe --version 1> gpg.ver
> 
>   Obviously a problem. I could, of course, write wrappers for all of
> those lib functions affected, but why should I?
>   Is the modified parsing intentional?
> 

libc066 changed the way to find a default shell. If you set UNIXROOT,
libc066 find /bin/sh first.

To avoid, there are two ways.

First, unset UNIXROOT in your program.
Second, prepend "cmd /c " to your string.

If you think this is wrong, open a ticket for kLIBC. And see
http://trac.netlabs.org/libc/ticket/287 first.

[toc] | [prev] | [next] | [standalone]

#1436

On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
>> Previously, a string like
>> 
>> D:\usr\bin\gpg.exe --version 1> gpg.ver
>>   was passed through unchanged. Now it becomes
>> D:usrbingpg.exe --version 1> gpg.ver
>> 
> libc066 changed the way to find a default shell. If you set UNIXROOT,
> libc066 find /bin/sh first.
>
  I am not sure we are talking about the same thing. I do not care about
the default shell; it is about how strings with backslashes are processed.

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#1437

 >   I do not care about the default shell

Probably you should care, because your system()-call is using it. 
Apparently the product isn't aimed at one specific shell, but you are 
using one specific shell (CMD.EXE, most likely) instead of some 
assumed shell.

 > it is about how strings with backslashes are processed.

W.r.t. a shell. Perhaps first try mr. Ko's suggestions first. Maybe 
the behaviour still is wrong, I'm not going to advocate why there's 
one assumed default, while there's not one specific target shell. 
Perhaps it shouldn't touch your "wrong" string, albeit I'm not 
familiar with the way the choosen default string processes 
backslashes. Maybe it has to modify the string.


--

[toc] | [prev] | [next] | [standalone]

#1438

Hi/2.

James Moe wrote:
> On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
>>> Previously, a string like
>>>
>>> D:\usr\bin\gpg.exe --version 1> gpg.ver
>>>   was passed through unchanged. Now it becomes
>>> D:usrbingpg.exe --version 1> gpg.ver
>>>
>> libc066 changed the way to find a default shell. If you set UNIXROOT,
>> libc066 find /bin/sh first.
>>
>   I am not sure we are talking about the same thing. I do not care about
> the default shell; it is about how strings with backslashes are processed.
> 

You should care about the default shell. Because system() uses the
default shell. And the default shell interprets your string.

Again, I suggest to execute your program after unsetting UNIXROOT. And
my second suggestion was wrong for this case.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

[toc] | [prev] | [next] | [standalone]

#1439

On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
> First, unset UNIXROOT in your program.
>
  I added setenv("UNIXROOT", "", 1) at the beginning of the program. It
made no difference.

  Here are outputs from attempts to use system():
sh: D:usrbingpg.exe: No such file or directory
sh: G:cvoicepmmdevtestcasebinstunnel.exe: No such file or directory

Regardless of any other consideration, libc066 has broken PMMail.
Updating libc should not do that.

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#1440

On Tue, 4 Nov 2014 17:28:42 UTC, James Moe 
<jimoeDESPAM@sohnen-moe.com> wrote:

> On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
> > First, unset UNIXROOT in your program.
> >
>   I added setenv("UNIXROOT", "", 1) at the beginning of the program. It
> made no difference.
> 
>   Here are outputs from attempts to use system():
> sh: D:usrbingpg.exe: No such file or directory
> sh: G:cvoicepmmdevtestcasebinstunnel.exe: No such file or directory
> 
> Regardless of any other consideration, libc066 has broken PMMail.
> Updating libc should not do that.
> 

This is very strange. I have been using Libc066 for about a week now, 
with PMMail (3.15), and I have seen no problems (I do use BogoFilter, 
and STunnel). My UNIXROOT points to <bootdrive>:\mptn\bin. Something 
else must be causing the problem.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1441

On 11/04/2014 11:58 AM, Doug Bissett wrote:
> I have been using Libc066 for about a week now, 
> with PMMail (3.15), and I have seen no problems
>
  Hm. I did a complete build of PMMail after updating libc. Maybe
pre-066 builds are safe.

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#1442

Hi/2.

James Moe wrote:
> On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
>> First, unset UNIXROOT in your program.
>>
>   I added setenv("UNIXROOT", "", 1) at the beginning of the program. It
> made no difference.
> 

You'd better use unset() rather than setenv(). And you seemed not to see
my second reply correctly. Execute your program *AFTER* unsetting
UNIXROOT not at the begining of the program.

>   Here are outputs from attempts to use system():
> sh: D:usrbingpg.exe: No such file or directory
> sh: G:cvoicepmmdevtestcasebinstunnel.exe: No such file or directory
> 
> Regardless of any other consideration, libc066 has broken PMMail.
> Updating libc should not do that.
> 

*ABSOLUTELY* agree.

Nevertheless, if you want to use '\', escape it with '\'. That is,
replace '\' with '\\'. Or if it is a path, replace '\' with '/'.

Anyway this is not universal, because the default shell may be changed
depending on UNIXROOT setting or some various conditions. See the
following for more deailts.

http://trac.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/lib/sys/b_processGetDefaultShell.c

That backend function was exported. So you can use that backend function
to get a default shell. And in according to it, you can reconstruct your
argument string.

Good luck.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

[toc] | [prev] | [next] | [standalone]

#1443

On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
> First, unset UNIXROOT in your program.
> Second, prepend "cmd /c " to your string.
>
  I tried #1: No change.
  I see no reason to modify the program for a defect in libc066.
  One of the error messages, "sh: D:usrbingpg.exe: [...]", gives a clue.
I searched for "sh.exe" on the UNIXROOT drive, and found one. I then
tried using the command string after having started a shell with sh.exe:
It failed in exactly the same way. Apparently that sh.exe is not built
to handle DOS-style strings.

$ sh --version
GNU bash, version 3.2.0(1)-release (i386-ibm-os2)
Copyright (C) 2005 Free Software Foundation, Inc.

  When I get time, I will update to libc066 again, and start PMMail two
different ways:
1. unset UNIXROOT before starting the program, leaving sh.exe as is
2. change to a [ba|c|a]sh.exe shell program that knows about DOS-style
command lines

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#1444

Hi/2.

James Moe wrote:
> On 11/03/2014 10:50 PM, KO Myung-Hun wrote:
>   I see no reason to modify the program for a defect in libc066.

Then open a ticket for kLIBC at netlabs.

>   One of the error messages, "sh: D:usrbingpg.exe: [...]", gives a clue.
> I searched for "sh.exe" on the UNIXROOT drive, and found one. I then
> tried using the command string after having started a shell with sh.exe:
> It failed in exactly the same way. Apparently that sh.exe is not built
> to handle DOS-style strings.
> 

This is what I've said so far.

>   When I get time, I will update to libc066 again, and start PMMail two
> different ways:
> 1. unset UNIXROOT before starting the program, leaving sh.exe as is
> 2. change to a [ba|c|a]sh.exe shell program that knows about DOS-style
> command lines
> 

If so, try -Zno-unix linker flags although it may introduce another
problem. And pdksh does what you want.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

[toc] | [prev] | [next] | [standalone]

#1446

On 11/05/2014 06:09 PM, James Moe wrote:
>   When I get time, I will update to libc066 again, and start PMMail two
> different ways:
> 1. unset UNIXROOT before starting the program, leaving sh.exe as is
>
  Works.

> 2. leave UNIXROOT set, change to a [ba|c|a]sh.exe shell program that knows about DOS-style
> command lines
>
  Does not work regardless of shell program. Backslashes are always
considered escape chars.

-- 
James Moe
jmm-list at sohnen-moe dot com

[toc] | [prev] | [next] | [standalone]

#1447

James Moe wrote:
>    One of the error messages, "sh: D:usrbingpg.exe: [...]", gives a clue.
> I searched for "sh.exe" on the UNIXROOT drive, and found one. I then
> tried using the command string after having started a shell with sh.exe:
> It failed in exactly the same way. Apparently that sh.exe is not built
> to handle DOS-style strings.
>
> $ sh --version
> GNU bash, version 3.2.0(1)-release (i386-ibm-os2)
> Copyright (C) 2005 Free Software Foundation, Inc.

The yum/rpm sh should be ash.exe installed as sh and sh.exe so you need 
to update or start over with your rmp install.
But yes, they seem to be adding workarounds to libc instead of the 
programs, quicker but not OS/2 friendly where backslashes are the 
expected path separator.
Dave

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.os2.programmer.misc

csiph-web