On Jan 11, 2017, at 4:01 PM, Jim Callahan <[email protected]>
wrote:
>
>> How much doing all that is worth is a different question, since the calls
> made through this
>> proposed system() SQLite function would also likely be non-portable. In
> this very example,
>> there is no wc on Windows.
>
> I would suggest renaming the proposed system() function bash()
Definitely not. Bash is not the only shell on POSIX systems, and system() or
popen() on such systems may or may not be calling Bash to do their work.
You also have the Windows option I brought up in my previous post; you wouldn’t
want to have to write a separate function called cmd() that only worked in
SQLite SQL when run on Windows.
I would suggest not calling it system(). C’s system() doesn’t work like the
proposed SQLite extension: you don’t get a way to capture the output. Calling
it popen() also doesn’t seem right.
Something like cmdsubst() seems more accurate. (Named after the POSIX “command
substitution” feature, which is what this proposed function would actually
provide.)
> now and in the future there may be different command line shells.
Sure, but naming the function bash() implies that the function would have to be
changed somehow to operate with these other shells. That’s not how POSIX
systems work: system() and popen() on POSIX systems use an
implementation-defined POSIX shell, which may or may not be Bash.
You shouldn’t care what shell system() and popen() use underneath. As long as
you give it a command in valid POSIX shell syntax, it should run correctly
everywhere the referenced external commands exist.
> The (now) new Windows 10 Anniversary Edition has the option of installing a
> shell that nearly runs Canonical Ubuntu Linux's BASH shell.
There are severe limitations to depending on that besides the fact that it
isn’t installed by default.
While you can run “bash -c 'some command'” from a native Windows executable and
capture its output, what happens inside the Bash environment under WSL is
largely firewalled off from the regular Windows environment except for I/O
interactions. (i.e. disk files, network traffic, etc.)
So for example, you couldn’t use WSL’s bash.exe via this SQLite extension to
detect whether notepad.exe is running:
cmdsubst('pgrep notepad.exe')
WSL has a separate process table from the native Windows one, so the pgrep
running under WSL can’t find notepad.exe, even if it is running.
> In a few years
> it will likely be a routine part of Windows.
I doubt it. You have to turn off a bunch of security mechanisms in Windows to
get it to run. (So-called “developer mode.”)
Unless they find a way to allow WSL to run without needing developer mode
privileges, installing WSL by default would effectively roll back all those
protections for everyone.
> Thus, at some point, Linux, OS/X and Windows will all support Bash scripts.
See, there’s where talking about “Bash” gets you into trouble.
I’ve got something like 10 Linux boxes in this room here with me that don’t
have Bash on them. They run Busybox[1] instead; its “sh” implementation is
based on the Almquist shell.[2]
[1] https://busybox.net/
[2] https://en.wikipedia.org/wiki/Almquist_shell
> For now, there are non-native emulators MinGW/MSys and Cygwin to provide
> Bash on Windows.
MSYS and Cygwin are neither non-native nor “emulators.” Executables produced
by the MSYS and Cygwin GCC compilers are, in fact, more “native” than WSL
executables.
WSL runs Linux ELF executables and implements the Linux kernel syscall
interface. Cygwin runs Windows PE executables and implements a POSIX/Linux
interface in terms of the native Windows API. MSYS is the same, being a fork
of Cygwin.
> Cygwin
> http://www.mingw.org/node/21
That’s a very one-sided argument.
Cygwin applications can call into the native Windows API. It is bad form to do
something via the native Windows API that Cygwin already provides, as there may
be cross-app interop considerations when you bypass the POSIX API that Cygwin
provides, but there is nothing actually stopping you from doing that.
In fact, one improvement made to SQLite a few years ago was to switch it from
using native Windows file locking when built under Cygwin to use POSIX or BSD
locking mechanisms, so that two programs built under Cygwin that both used
SQLite would get the advisory locking semantics they expect, not the mandatory
locking semantics Windows gives you by default. (It’s more complicated than
that, but I don’t want to go deeper into it here.)
Instead of letting the MinGW people tell you what Cygwin is, how about you let
the Cygwin project speak for themselves:
https://cygwin.com/cygwin-ug-net/programming.html
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
