hey, are you using docker on mac?
Bug #915: Please help
31–40 of 97 posts
Re: Bug #915: Please help
#32hey, are you using docker on mac?
In my reproduction, yes. But the original failure was on Travis, which I doubt is using docker on mac.
Re: Bug #915: Please help
#33Earlier quoted context omitted.
It might be easiest to view it like so: $ echo The shell spawns two commands connected to pipes, then replaces those with a file that represents the other (read) side of that pipe. The command above with >(grep something) does the same thing, just with the other end of a pipe.
It's not actually a pipe. >, This is explained in more detail here: https://askubuntu.com/questions/172982/what-is-the-differenc...
On linux at least, these two constructions are effectively identical from the view of the "piped" process.
# cat /dev/pts/0
l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20519634]
lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23611/fd/
# ls -l /proc/self/fd/ | cat -
total 0
lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0
l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20518265]
lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23621/fd/Re: Bug #915: Please help
#34Earlier quoted context omitted.
It's not actually a pipe. >, This is explained in more detail here: https://askubuntu.com/questions/172982/what-is-the-differenc...
On linux at least, these two constructions are effectively identical from the view of the "piped" process. # cat /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20519634] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23611/fd/ # ls -l /proc/self/fd/ | cat - total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 J…
Yes, because “cat” can use either STDIN or a file as input:
https://github.com/coreutils/coreutils/blob/master/src/cat.c...
It’s an intentional design decision.
Re: Bug #915: Please help
#35Earlier quoted context omitted.
It might be easiest to view it like so: $ echo The shell spawns two commands connected to pipes, then replaces those with a file that represents the other (read) side of that pipe. The command above with >(grep something) does the same thing, just with the other end of a pipe.
It's not actually a pipe. >, This is explained in more detail here: https://askubuntu.com/questions/172982/what-is-the-differenc...
It is a pipe, just for a different definition of pipe.
| is the pipe operator in sh for doing a shell "pipeline". However, the parent comment is referring to a linux pipe as in pipe(7) [0].
One easy way to see this is with the following:
$ ls -l 'pipe:[2937585]'
Those file descriptors were created using the pipe(2)[1] call by the shell, so it seems fine to refer to them to pipes.
I'll also note that () are _not_ using the "redirection operator". They're actually distinct operators for "process substitution"[2] in bash terminology. They look similar to redirects, but they're not the same operator, so that stack overflow answer isn't really relevant.
[0]: http://man7.org/linux/man-pages/man7/pipe.7.html
Re: Bug #915: Please help
#36Earlier quoted context omitted.
On linux at least, these two constructions are effectively identical from the view of the "piped" process. # cat /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20519634] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23611/fd/ # ls -l /proc/self/fd/ | cat - total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 J…
Yes, because “cat” can use either STDIN or a file as input: https://github.com/coreutils/coreutils/blob/master/src/cat.c... It’s an intentional design decision.
I think we're probably in agreement, but we're getting caught up on the definition of "piping".
In my case I'm using it to describe the use of a kernel pipe object. In your case, you are using it to describe the higher-level concept of connection from one processes stdout to another process's stdin (or something along those lines).
Re: Bug #915: Please help
#37Earlier quoted context omitted.
It's not actually a pipe. >, This is explained in more detail here: https://askubuntu.com/questions/172982/what-is-the-differenc...
It is a pipe, just for a different definition of pipe. | is the pipe operator in sh for doing a shell "pipeline". However, the parent comment is referring to a linux pipe as in pipe(7) [0]. One easy way to see this is with the following: $ ls -l 'pipe:[2937585]' As you can see, that command created a fd (16) which referred to a pipe (pipe:[2937585]). Those file descriptors were created using the pipe(2)[1] call by th…
On POSIX systems, the line between file and pipe doesn’t exist. If you create a named pipe w/ mknod or mkfifo, you would interact with the named pipe as you would a normal file. Or block/character device. Etc.
In case of unnamed pipe the fds just exist as long as the process is running, then it disappears. Point is it’s irrelevant what you refer to as pipe, at the end of the day some file-like object is either written to or read from. And really, that file-like object is actually just a buffer.
Re: Bug #915: Please help
#38Unfortunately, the sqlite3 python interface doesn't expose Sqlite's extended error info so that you could see what's happening.
https://bugs.python.org/issue16379
There an uncommitted patch to get the extended error in this other, related issue: https://bugs.python.org/issue24139
Or maybe just try cffi or ctypes in python to call sqlite3_errcode(), sqlite3_extended_errcode() and sqlite3_errmsg(). The incantation to find an already linked sqlite3 lib:
import ctypes
import ctypes.util
sqlite = ctypes.CDLL(ctypes.util.find_library('sqlite3'))
Re: Bug #915: Please help
#39Re: Bug #915: Please help
#40Can we please have an informative title?
Bug #915: Please help tells me nothing.