On Mon, Mar 19, 2018 at 03:39:46PM +0000, CB Bailey wrote: > > diff --git a/git-filter-branch.sh b/git-filter-branch.sh > > index 1b7e4b2cd..21d84eff3 100755 > > --- a/git-filter-branch.sh > > +++ b/git-filter-branch.sh > > @@ -627,7 +627,7 @@ then > > print H "$_:$f\n" or die; > > } > > close(H) or die;' || die "Unable to save state") > > - state_tree=$(/bin/echo -e "100644 blob $state_blob\tfilter.map" | git mktree) > > + state_tree=$(printf '100644 blob %s\tfilter.map\n' "$state_blob" | git mktree) > > if test -n "$state_commit" > > then > > state_commit=$(/bin/echo "Sync" | git commit-tree "$state_tree" -p "$state_commit") > > I think the change from 'echo -e' to printf is good because of the > better portability reason that you cite. > > Looking at the change, I am now curious as to why '/bin/echo' is used. > Testing on a Mac, bash's built in 'echo' recognizes '-e' whereas > '/bin/echo' does not. This is just an observation, I still prefer the > move to 'printf' that you suggest. Right. Moving them to just "echo -e" would work on systems where /bin/sh is bash, but not elsewhere (e.g., Debian systems with "dash" whose built-in echo doesn't understand "-e"). So my guess as to why /bin/echo was used is that on Linux systems it's _more_ predictable and portable, because you know you're always going to get the GNU coreutils version, which knows "-e". Even if you're using a non-bash shell. But on non-Linux systems, who knows what system "echo" you'll get. :) Author cc'd in case there's something more interesting going on. -Peff
