I have a simple script, that is essentially a list of dpkg -i ... commands in a chroot.

It looks something like this:

chroot /path/to/chroot /bin/bash -e << EOF
cd /opt

dpkg -i package1_*

dpkg -i package50_*
dpkg -i package51_*

dpkg -i package100_*


The problem is, when I call the script like, bash -c "script here" or bash <( echo "script here" ), i get an error message.

The error message looks something like:

Selecting previously unselected package libss2:i386.
(Reading database ... 1376 files and directories currently installed.)
Preparing to unpack libss2_1.42.9-3ubuntu1_i386.deb ...
Unpacking libss2:i386 (1.42.9-3ubuntu1) ...
Setting up libss2:i386 (1.42.9-3ubuntu1) ...
Processing triggers for libc-bin (2.19-0ubuntu6.5) ...
/bin/bash: d: not found

It seems like the code is cut off at d(pkg -i ...).

I changed the dpkg that is being cut off to an echo. The error message stayed the same, only that now e is not being found.

I could of course save the script in a temp file and call it, since that works. But I would like to know what is happening here. The cutoff mark (including the 'd') is at the 1048 byte point.

  • I cannot reproduce this behavior. Is there a difference between bash <( echo "script here") and bash <( cat scriptfile )? (Where the file scriptfile contains your script.)
    – michas
    Feb 9, 2015 at 13:17
  • 3
    Probably one of those dpkg -i commands is reading from stdin (which is that here-script). Try bash /dev/fd/3 3<< EOF... or bash -c "$(cat << EOF...)" instead. Feb 9, 2015 at 13:31
  • @michas That did work. Good alternative. but what if my script is the output of another command?
    – Minix
    Feb 9, 2015 at 13:38
  • @StéphaneChazelas: There are. So the bytes they try to read in as an answer are the missing bytes at the end?
    – Minix
    Feb 9, 2015 at 13:52


Browse other questions tagged .