Re: [ast-developers] libcmd builtin wish: iconv
On 26 September 2012 10:57, Cedric Blancher wrote: > On 26 September 2012 06:09, Lionel Cons wrote: >> On 27 August 2012 22:22, Glenn Fowler wrote: >>> >>> I took a quick look and iconv(1) does look like a good candidate for -lcmd >>> it would just need an sh signal check in the inner file loop >> >> Could you add this for the next alpha/beta or what comes next, please? >> I personally ran afoul of the lack of iconv this night on almost 70 of >> our machines and DO have a grudge against that thing. > > Hey, where's your usual request for grep? :) Nay, we've given up on that. I'm in a wheelchair with grey hair when this happens. We've elaborated the options and came to the conclusion that none will work: External AST grep is too slow, the .paths solution so desperately defended by David and Glenn is not deployable on a site like CERN (b'cause we can't guarantee that nothing else breaks except ksh93 when there is an extra .paths file in /usr/bin) and generally if the default ksh93 builtin doesn't include it the we have to convince every Linux vendor under this Sun to adopt the same patches or deploy our own ksh93 binaries for every single installation at our site. That's possible but costly. The solution for us was to abandon ksh93 and port the affected applications to perl instead. That's ugly but we've left with no other acceptable choice. Lionel ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On 26 September 2012 06:09, Lionel Cons wrote: > On 27 August 2012 22:22, Glenn Fowler wrote: >> >> I took a quick look and iconv(1) does look like a good candidate for -lcmd >> it would just need an sh signal check in the inner file loop > > Could you add this for the next alpha/beta or what comes next, please? > I personally ran afoul of the lack of iconv this night on almost 70 of > our machines and DO have a grudge against that thing. Hey, where's your usual request for grep? :) Ced -- Cedric Blancher Institute Pasteur ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On 27 August 2012 22:22, Glenn Fowler wrote: > > I took a quick look and iconv(1) does look like a good candidate for -lcmd > it would just need an sh signal check in the inner file loop You have to remove the call to setlocale() too. Lionel ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On 27 August 2012 22:22, Glenn Fowler wrote: > > I took a quick look and iconv(1) does look like a good candidate for -lcmd > it would just need an sh signal check in the inner file loop Could you add this for the next alpha/beta or what comes next, please? I personally ran afoul of the lack of iconv this night on almost 70 of our machines and DO have a grudge against that thing. > > On Mon, 20 Aug 2012 00:47:03 +0200 Lionel Cons wrote: >> Glenn, it may be useful to add iconv to libcmd. We figured (after >> comments in the main XML development list [xml-...@lists.xml.org]) it >> might be useful for XML processing in case we encounter UCS2 or UCS4 >> encoded XML documents (for example originating from Windows) but the >> platform does not have iconv installed. > >> Lionel >> ___ >> ast-developers mailing list >> ast-developers@research.att.com >> https://mailman.research.att.com/mailman/listinfo/ast-developers > Lionel ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On Fri, Sep 14, 2012 at 3:27 PM, Simon Toedt wrote: > On Wed, Aug 29, 2012 at 5:07 PM, David Korn wrote: >> Subject: Re: Re: [ast-developers] libcmd builtin wish: iconv >> >> >> >>> We need a single ksh binary with grep builtin. If we deploy multiple >>> files with .paths then we have to convince at least 11 groups at our >>> site that this makes sense, doesn't affect them and is worth to put >>> this on the agenda of lots of meetings. Not to mention the yapping >>> about using perl instead. >>> >> >> We want to do this as a compile option but we would like to associate >> grep with a path, most likely the one found in the standard path. >> This will allow a user to override the one we provide. > > You do have /opt/ast (or /usr/ast on some platforms) for that. > > Sorry for asking a question which may have been discussed: Why does it > take that long to add grep to ksh93? Again. I will never understand it why this can't be a compile option. It has been requested so often. Simon ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On Fri, Sep 14, 2012 at 5:00 PM, Glenn Fowler wrote: > > On Fri, 14 Sep 2012 15:27:35 +0200 Simon Toedt wrote: >> On Wed, Aug 29, 2012 at 5:07 PM, David Korn wrote: >> > Subject: Re: Re: [ast-developers] libcmd builtin wish: iconv >> > >> > >> > >> >> We need a single ksh binary with grep builtin. If we deploy multiple >> >> files with .paths then we have to convince at least 11 groups at our >> >> site that this makes sense, doesn't affect them and is worth to put >> >> this on the agenda of lots of meetings. Not to mention the yapping >> >> about using perl instead. >> >> >> > >> > We want to do this as a compile option but we would like to associate >> > grep with a path, most likely the one found in the standard path. >> > This will allow a user to override the one we provide. > >> You do have /opt/ast (or /usr/ast on some platforms) for that. > >> Sorry for asking a question which may have been discussed: Why does it >> take that long to add grep to ksh93? > > the coding could be and has been done in minutes > > but > > although ast grep (or other ast command => builtin candidates) may be posix > compliant > they are not necessarily compliant > > providing a PATH-based way for users to explicitly enable ast builtins is an > opt-in > users finding incompatibilities between ast-builtin-foo and > native-standalone-foo > can deal with that by selectively opting-in and opting-out via PATH > manipulation > using the same mechanism that has been used since 1970 to dance between > different > standalone foo implementations using PATH Glenn, apologies for being direct and blunt, but... can you just for god damns sake just add the damn grep, od, tr and xargs builtins to libcmd to see what the damn exactly happens instead of damn speculating? AST is in an alpha phase right now and experimentation IS allowed. if we can get more happy users with that, lets do that. Please. Josh ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On Fri, 14 Sep 2012 15:27:35 +0200 Simon Toedt wrote: > On Wed, Aug 29, 2012 at 5:07 PM, David Korn wrote: > > Subject: Re: Re: [ast-developers] libcmd builtin wish: iconv > > > > > > > >> We need a single ksh binary with grep builtin. If we deploy multiple > >> files with .paths then we have to convince at least 11 groups at our > >> site that this makes sense, doesn't affect them and is worth to put > >> this on the agenda of lots of meetings. Not to mention the yapping > >> about using perl instead. > >> > > > > We want to do this as a compile option but we would like to associate > > grep with a path, most likely the one found in the standard path. > > This will allow a user to override the one we provide. > You do have /opt/ast (or /usr/ast on some platforms) for that. > Sorry for asking a question which may have been discussed: Why does it > take that long to add grep to ksh93? the coding could be and has been done in minutes but although ast grep (or other ast command => builtin candidates) may be posix compliant they are not necessarily compliant providing a PATH-based way for users to explicitly enable ast builtins is an opt-in users finding incompatibilities between ast-builtin-foo and native-standalone-foo can deal with that by selectively opting-in and opting-out via PATH manipulation using the same mechanism that has been used since 1970 to dance between different standalone foo implementations using PATH compiling a builtin directly into a ksh executable is an entirely new vector the implications of which are not completely understood *and in addition and reiterating* the conversion of formerly stanadlone commands to builtins is not yet a bug-free process there are still interactive problems with signals that are being worked out its much better working those problems out with experienced users who explicitly opt-in rather than using the m$ model of making everyone a debugger by default and its much easier to change PATH than to apply a patch and redeploy ksh and, for the purposes of testing new vectors, its much easier to be able to separate builtin problems from ksh proper Roland has provided a patch for those users who want to opt-in at compile time but at the moment we would rather not add compiled-in-builtins to the debugging todo list so the patch is not the default ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On Wed, Aug 29, 2012 at 5:07 PM, David Korn wrote: > Subject: Re: Re: [ast-developers] libcmd builtin wish: iconv > > > >> We need a single ksh binary with grep builtin. If we deploy multiple >> files with .paths then we have to convince at least 11 groups at our >> site that this makes sense, doesn't affect them and is worth to put >> this on the agenda of lots of meetings. Not to mention the yapping >> about using perl instead. >> > > We want to do this as a compile option but we would like to associate > grep with a path, most likely the one found in the standard path. > This will allow a user to override the one we provide. You do have /opt/ast (or /usr/ast on some platforms) for that. Sorry for asking a question which may have been discussed: Why does it take that long to add grep to ksh93? Simon ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: Re: [ast-developers] libcmd builtin wish: iconv
Subject: Re: Re: [ast-developers] libcmd builtin wish: iconv > We need a single ksh binary with grep builtin. If we deploy multiple > files with .paths then we have to convince at least 11 groups at our > site that this makes sense, doesn't affect them and is worth to put > this on the agenda of lots of meetings. Not to mention the yapping > about using perl instead. > We want to do this as a compile option but we would like to associate grep with a path, most likely the one found in the standard path. This will allow a user to override the one we provide. David Korn d...@research.att.com ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On 29 August 2012 15:00, Glenn Fowler wrote: > > grep is available for testing via .paths We need a single ksh binary with grep builtin. If we deploy multiple files with .paths then we have to convince at least 11 groups at our site that this makes sense, doesn't affect them and is worth to put this on the agenda of lots of meetings. Not to mention the yapping about using perl instead. > so it depends how bitter grep problems are vs trying .paths You're kidding, are you? Try to process Unicode characters with /usr/bin/grep in Solaris. Please try it yourself. > > On Wed, 29 Aug 2012 12:03:15 +0200 Lionel Cons wrote: >> On 27 August 2012 22:22, Glenn Fowler wrote: >> > >> > I took a quick look and iconv(1) does look like a good candidate for -lcmd >> > it would just need an sh signal check in the inner file loop > >> What about grep? I still think this would be a great idea; I say that >> out of bitter experience with yet another run-in with AIX and Solaris >> grep. > >> > >> > On Mon, 20 Aug 2012 00:47:03 +0200 Lionel Cons wrote: >> >> Glenn, it may be useful to add iconv to libcmd. We figured (after >> >> comments in the main XML development list [xml-...@lists.xml.org]) it >> >> might be useful for XML processing in case we encounter UCS2 or UCS4 >> >> encoded XML documents (for example originating from Windows) but the >> >> platform does not have iconv installed. >> > >> >> Lionel >> >> ___ >> >> ast-developers mailing list >> >> ast-developers@research.att.com >> >> https://mailman.research.att.com/mailman/listinfo/ast-developers >> > > >> Lionel > Lionel ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
grep is available for testing via .paths so it depends how bitter grep problems are vs trying .paths On Wed, 29 Aug 2012 12:03:15 +0200 Lionel Cons wrote: > On 27 August 2012 22:22, Glenn Fowler wrote: > > > > I took a quick look and iconv(1) does look like a good candidate for -lcmd > > it would just need an sh signal check in the inner file loop > What about grep? I still think this would be a great idea; I say that > out of bitter experience with yet another run-in with AIX and Solaris > grep. > > > > On Mon, 20 Aug 2012 00:47:03 +0200 Lionel Cons wrote: > >> Glenn, it may be useful to add iconv to libcmd. We figured (after > >> comments in the main XML development list [xml-...@lists.xml.org]) it > >> might be useful for XML processing in case we encounter UCS2 or UCS4 > >> encoded XML documents (for example originating from Windows) but the > >> platform does not have iconv installed. > > > >> Lionel > >> ___ > >> ast-developers mailing list > >> ast-developers@research.att.com > >> https://mailman.research.att.com/mailman/listinfo/ast-developers > > > Lionel ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
On 27 August 2012 22:22, Glenn Fowler wrote: > > I took a quick look and iconv(1) does look like a good candidate for -lcmd > it would just need an sh signal check in the inner file loop What about grep? I still think this would be a great idea; I say that out of bitter experience with yet another run-in with AIX and Solaris grep. > > On Mon, 20 Aug 2012 00:47:03 +0200 Lionel Cons wrote: >> Glenn, it may be useful to add iconv to libcmd. We figured (after >> comments in the main XML development list [xml-...@lists.xml.org]) it >> might be useful for XML processing in case we encounter UCS2 or UCS4 >> encoded XML documents (for example originating from Windows) but the >> platform does not have iconv installed. > >> Lionel >> ___ >> ast-developers mailing list >> ast-developers@research.att.com >> https://mailman.research.att.com/mailman/listinfo/ast-developers > Lionel ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
Re: [ast-developers] libcmd builtin wish: iconv
I took a quick look and iconv(1) does look like a good candidate for -lcmd it would just need an sh signal check in the inner file loop On Mon, 20 Aug 2012 00:47:03 +0200 Lionel Cons wrote: > Glenn, it may be useful to add iconv to libcmd. We figured (after > comments in the main XML development list [xml-...@lists.xml.org]) it > might be useful for XML processing in case we encounter UCS2 or UCS4 > encoded XML documents (for example originating from Windows) but the > platform does not have iconv installed. > Lionel > ___ > ast-developers mailing list > ast-developers@research.att.com > https://mailman.research.att.com/mailman/listinfo/ast-developers ___ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
