Return to Answer

tail -n 99 test.sh | bash

tail needs to read to the end of the file before it knows if it's going to echo the first line.

F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bash

is a bit more robust because it avoids the assumption that your file is under 99 lines.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

is another option that is even more robust (can't run out of memory) and just as fast (assuming tmpfs)

touching the original file should be avoided so that hard links, last modified time, and read locks are not disturbed, that way you can leave an editor open while running the file and rsync won't needlessly checksum the file for backups and hard links function as expected.

replacing the file on edit would work but is less robust because it's not enforceable to other scripts/users/or one might forget. And again it would break hard links.

Wrapping your script in a block {} is likely the best option but requires changing your scripts.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

would be the second best option (assuming tmpfs) the disadvantage is it breaks $0 if your scripts use that.

using something like F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bash is less ideal because it has to keep the whole file in memory and breaks $0.

touching the original file should be avoided so that, last modified time, read locks, and hard links are not disturbed. that way you can leave an editor open while running the file and rsync won't needlessly checksum the file for backups and hard links function as expected.

replacing the file on edit would work but is less robust because it's not enforceable to other scripts/users/or one might forget. And again it would break hard links.

tail -n 99 test.sh | bash

tail needs to read to the end of the file before it knows if it's going to echo the first line.

F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bash

is a bit more robust because it avoids the assumption that your file is under 99 lines.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

is another option that might be more reliable and should be as fast (assuming tmpfs)

touching the original file should be avoided so that hard links, last modified time, and read locks are not disturbed, that way you can leave an editor open while running the file and rsync won't needlessly checksum the file for backups and hard links function as expected.

replacing the file on edit would work but is less robust because it's not enforceable to other scripts/users/or one might forget. And again it would break hard links.

tail -n 99 test.sh | bash

tail needs to read to the end of the file before it knows if it's going to echo the first line.

F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bash

is a bit more robust because it avoids the assumption that your file is under 99 lines.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

is another option that is even more robust (can't run out of memory) and just as fast (assuming tmpfs)

touching the original file should be avoided so that hard links, last modified time, and read locks are not disturbed, that way you can leave an editor open while running the file and rsync won't needlessly checksum the file for backups and hard links function as expected.

replacing the file on edit would work but is less robust because it's not enforceable to other scripts/users/or one might forget. And again it would break hard links.

tail -n 99 test.sh | bash

tail needs to read to the end of the file before it knows if it's going to echo the first line.

F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bash

is a bit more robust because it avoids the assumption that your file is under 99 lines.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

is another option that might be more reliable and should be as fast (assuming tmpfs)

touching the original file should be avoided so that hard links, last modified time, and read locks are not disturbed, that way you can leave an editor open while running the file and rsync won't needlessly checksum the file for backups and hard links function as expected.

tail -n 99 test.sh | bash

tail needs to read to the end of the file before it knows if it's going to echo the first line.

F=test.sh; tail -n $(cat "$F" | wc -l) "$F" | bash

is a bit more robust because it avoids the assumption that your file is under 99 lines.

F=$(mktemp) && cp test.sh $F && bash $F; rm $F;

is another option that might be more reliable and should be as fast (assuming tmpfs)

touching the original file should be avoided so that hard links, last modified time, and read locks are not disturbed, that way you can leave an editor open while running the file and rsync won't needlessly checksum the file for backups and hard links function as expected.

replacing the file on edit would work but is less robust because it's not enforceable to other scripts/users/or one might forget. And again it would break hard links.