<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Loïc Grenié wrote: <blockquote cite="mid:9b06e8d21002090955x3bfd45bciafc44f9869b2401d@mail.gmail.com" type="cite"> <pre wrap="">2010/2/9 Mihamina Rakotomandimby <a class="moz-txt-link-rfc2396E" href="mailto:mihamina@gulfsat.mg"><mihamina@gulfsat.mg></a>: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Loïc Grenié <a class="moz-txt-link-rfc2396E" href="mailto:loic.grenie@gmail.com"><loic.grenie@gmail.com></a> : #!/bin/sh exit 1 </pre> </blockquote> <pre wrap="">This will launch one "sh". Is it really smaller in footprint? I dont know. </pre> </blockquote> <pre wrap=""> Yes and no, sh/bash/dash is probably already in memory for some (many) shell-scripts. </pre> </blockquote> The same thing goes for /bin/false _and_ a decent shell will cash the inode for it. <blockquote cite="mid:9b06e8d21002090955x3bfd45bciafc44f9869b2401d@mail.gmail.com" type="cite"> <pre wrap="">Since most of the memory </pre> </blockquote> That is a daring statement, especially for something involved like, say bash. I'd be willing to be bet that it is 50% at most that is shared. Don't forget that a silly thing like stacks or libreadline heap can really ruin the shared mem ratio <blockquote cite="mid:9b06e8d21002090955x3bfd45bciafc44f9869b2401d@mail.gmail.com" type="cite"> <pre wrap="">is shared between processes (read-only memory of processes and libraries is shared), memory footprint won't change much whether you launch this script or not. </pre> </blockquote> Only if the shell could 'optimize out' the fork/exec to the shell process. I'm pretty sure that cannot be allowed under any POSIX compliant shell. I have even been lead to assume that the interpretation of #! is actually more of a _kernel_ loader feature than a shell feature (I might be mistaken here). So, you'd get the hit for initializing a process, attaching stdin/stdout/stderr, setting up a shell environment, sourcing profiles (beware /etc/bash_completion and their kin) _parsing_ the command line and then interpreting the commands. That is a slew of overhead even comparing with GNU coreutils/false; <blockquote cite="mid:9b06e8d21002090955x3bfd45bciafc44f9869b2401d@mail.gmail.com" type="cite"> <pre wrap=""> Whether this is a sensible idea or not, I leave it to more knowledgeable people. </pre> </blockquote> I bet, if you wanted to 'script' your way out of a memory/disk footprint and make a ridiculous sacrifice in the CPU/mem footprint instead you'd have to go perl/python/ruby it in a holistic fashion (so avoid the execs and instead use language-native constructs) <blockquote cite="mid:9b06e8d21002090955x3bfd45bciafc44f9869b2401d@mail.gmail.com" type="cite"> <pre wrap=""> Loïc </pre> </blockquote> Seth </body> </html>