On Jan 11, 2017, at 4:01 PM, Jim Callahan <jim.callahan.orla...@gmail.com> 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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users