> At least I think that is what you suggest, and think it just
> may work! But I could be wrong!
Yes, that's exactly what I suggest.
Pavel
On Thu, Sep 17, 2009 at 1:18 PM, John <jhy...@earthlink.net> wrote:
> Pavel Ivanov wrote:
>>> I'd rather avoid building sqlite3 under cygwin. I would like
>>> to keep as much as possible in native code, compromising only
>>> on cygwin to run my scripts.
>>
>> And this is root of your problem. Using mix of cygwin-native
>> applications with windows-native applications will always have such
>> problem.
>>
>>> When installing cygwin, you it offers you the choice to switch
>>> to default text file type to DOS (\r\n). Should I try that?
>>
>> Don't do that. This mode of operation is not supported much and not
>> recommended by cygwin developers and it reportedly will significantly
>> slow down cygwin's operation.
>>
>>> So I guess my question here is, do any sqlite users here
>>> have experience fixing this on Windows for Unix cygwin
>>> script calls?
>>
>> The major suggestion here: write some "windows native code launcher"
>> that will be used for running all non-cygwin applications (this can be
>> just function in the script). It will do nothing on unix platforms
>> (select your own preferred way of distinguishing it) and it will
>> always strip off '\r' from output of running application on windows
>> (you can use sed for that). And there's nothing else you can do about
>> it.
>
> This sounds like a great idea. I can have all sqlite3.exe calls
> "intercepted" by another script call like:
>
> NumPar=`WINDOWSCALL Program Arguments`
>
> WINDOWSCALL is the launcher that calls Program sqlite3.exe
> with its arguments and strips off any trailing \r's
> and returns that string to the caller through stdout,
> as to NumPar here. WINDOWSCALL can do nothing on Unix/MacOS,
> and fix the string on Windows.
>
> At least I think that is what you suggest, and think it just
> may work! But I could be wrong!
>
> Thanks! I'll try coding it.
>
>> Pavel
>>
>> On Thu, Sep 17, 2009 at 12:26 PM, John <jhy...@earthlink.net> wrote:
>>> I am writing some Unix scripts on Mac OS X that use
>>> sqlite3. Since the program could be useful to those
>>> on Windows, I figured I'd see if they worked under
>>> cygwin.
>>>
>>> A lot of it works, but calling sqlite3.exe from
>>> cygwin and returning a string with the value
>>> returned from the database seems to attach a
>>> "\r" that expr doesn't remove.
>>>
>>> That is:
>>>
>>> NumPar=`sqlite3.exe ${DATABASE} "SELECT NumPar FROM citations WHERE
>>> X='Key' ;"`
>>>
>>> NumPar comes back as: "12\r"
>>>
>>> and
>>>
>>> NumPar=`expr ${NumPar}`
>>>
>>> doesn't convert it to integer, as the subsequent test fails because
>>> of NumPar being non-integer (it isn't complaining about N, that
>>> is integer in the code):
>>>
>>> if [ ${N} -le ${NumPar} ]
>>> ...
>>>
>>> I can fix this case by:
>>>
>>> NumPar=`printf '%s' "${NumPar}" | sed 's/[^0-9]//g'`
>>>
>>> but then other scripts fail later, presumably because of
>>> strings with \r on them. (I suppose I can use sed to
>>> always remove \r's on every one of these calls, but
>>> that seems pretty kludgy, especially since "clean"
>>> Mac OS X handles all this "properly" without that.
>>> I'm hoping to find an elegant solution.
>>>
>>> I'd rather avoid building sqlite3 under cygwin. I would like
>>> to keep as much as possible in native code, compromising only
>>> on cygwin to run my scripts.
>>>
>>> When installing cygwin, you it offers you the choice to switch
>>> to default text file type to DOS (\r\n). Should I try that?
>>> My pretty serious objection to that would be that any users
>>> already using cygwin with the "correct" default settings would
>>> not be able to use the scripts anyway.
>>>
>>> So I guess my question here is, do any sqlite users here
>>> have experience fixing this on Windows for Unix cygwin
>>> script calls?
>>>
>>> Thanks!
>>> _______________________________________________
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
