Re: bash uses tmp files for inter-process communication instead of pipes?

[Chet Ramey]

On 10/6/14, 5:00 PM, Linda Walsh wrote:

>> You are working in a severely constrained environment. 
> That isn't the problem:  the assignment using a tmp file is:
>> strace -p 48785 -ff
> Process 48785 attached
> read(0, "\r", 1)                        = 1
> write(2, "\n", 1)                       = 1
> socket(PF_NETLINK, SOCK_RAW, 9)         = 3
> sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
> msg_iov(2)=[{"*\0\0\0d\4\1\0\0\0\0\0\0\0\0\0", 16}, {"read a b c d
> <<<${arr[@]}\0", 26}], msg_controllen=0, msg_flags=0}, 0) = 42
> close(3)                                = 0
> -----
> Um... it used a socket.. to transfer it, then it uses a tmp file on top
> of that?!  :

Slow down and read the trace, espcially the data being transferred.  This
is syslog saving the command.

> rt_sigaction(SIGINT, {0x4320b1, [], SA_RESTORER|SA_RESTART, 0x30020358d0},
> {0x4320b1, [], SA_RESTORER|SA_RESTART, 0x30020358d0}, 8) = 0
> open("/tmp/sh-thd-110678907923", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3
> write(3, "one two three four", 18)      = 18
> write(3, "\n", 1)                       = 1
> open("/tmp/sh-thd-110678907923", O_RDONLY) = 4
> close(3)                                = 0
> unlink("/tmp/sh-thd-110678907923")      = 0
> fcntl(0, F_GETFD)                       = 0
> fcntl(0, F_DUPFD, 10)                   = 10
> fcntl(0, F_GETFD)                       = 0
> fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
> dup2(4, 0)                              = 0
> close(4)                                = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
> 0x7fff85627820) = -1 ENOTTY (Inappropriate ioctl for device)
> lseek(0, 0, SEEK_CUR)                   = 0
> read(0, "one two three four\n", 128)    = 19
> dup2(10, 0)                             = 0
> fcntl(10, F_GETFD)                      = 0x1 (flags FD_CLOEXEC)
> close(10)                               = 0
> -----
> 
> Why in gods name would it use a socket (still of arguable overhead, when
> it could be done in a local lib), but THEN it duplicates the i/o in a file?

Read the trace.  There's no duplication going on.  The shell uses temp
files to implement here documents -- an implementation choice you may
disagree with under your peculiar circumstances but one that is simple
and general.


>> Maybe the best solution here is to move your script to a different part
>> of the boot sequence.  If you run it after all the local file systems
>> have been mounted, then you should be able to create temporary files,
>> which in turns means << and <<< become available, should you need them.
> ----
>     Theoretically, they ARE mounted.... What I think may be happening
> is that $TMP is not set so it is trying to open the tmp dir in:
> 
> "//sh-thd-183928392381" -- a network address.

This is not a network address.  The pathname you've shown is consistent
with TMPDIR being set to a single slash (TMPDIR=/), which is a directory
writable by the current user.

You might try setting TMPDIR=/tmp in your startup script.


> ---
>     Correctness before elegance.  1), use memory before OS services.
> 2) use in-memory services before file services, 3) Don't use uninitialized
> variables (TMP) -- verify that they are sane values before usage.
> 4) don't use network for tmp when /tmp or /var/tmp would have worked just
> fine.

This is basically word salad.


>  This type of redirection instructs the shell to  read  input  from  the
>        current source until a line containing only delimiter (with no trailing
>        blanks) is seen.  All of the lines read up to that point are then  used
>        as the standard input for a command.
> 
> "The current source" -- can be anything that input can be
> redirected from -- including memory.

In your case, the current source is the script, where the data appears.

>     How could you use a seek in the middle of a HERE doc
> read?

Think about your use cases.  Many programs check whether or not their
input is a seekable device so they can read more than one character at
a time.

> Not only that, it's just wrong.    /dev/stdin most often comes from
> a tty which is not random access.

Again, it depends on your use cases.  There are a number of programs
whose primary use is in a filter environment rather than directly by
a user at a terminal.

>>> Creating a tmp file to do an assignment, I assert is a bug.

You're still mixing a general capability with your use of that capability.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/