So, it seems safe to replace all occurences of "echo -n " with "printf ", what about speed or weird side effects?
Search and replace is our friend, people... ________________ Miguel de Benito. On Wed, Jul 25, 2012 at 9:10 PM, Sam Liddicott <[email protected]> wrote: > Your well expressed comments do not fit the question. > > I wonder if you realised that printf is a shell built-in command with better > portability than echo, and here does not refer to the C library. > > Sam > > On Jul 25, 2012 8:04 PM, "Adrian S." <[email protected]> wrote: >> >> I am against making it a requirement. I think plugins are to be >> mantained, and if the one who writes them knows C, he can write them >> in C; if he knows bash; he could write them in bash. >> >> If compatibility issues were the main concern, we could let people >> know about the caveats of using each programming language, and some >> guidelines about what kinds of plugins are guaranteed or more likely >> to work in all environments... I am afraid that, in that case, any >> *nix shell would not meet the crossplatform criteria. >> >> People would debate on "We suggests that you..." vs "We demand that >> you..."; but, either way, both could agree on "We want to make you >> aware of...". >> >> I am familiar with the issue, since a long time ago there was a push >> to remove all the >> echo -ne >> and then only use standard shell techniques... I don't think it >> worked well. And then ubuntu make a softlink from /usr/bin/sh to >> /usr/bin/dash instead of /usr/bin/bash; which all of a sudden broke a >> lot of plugings, because they were changed to #!/bin/bash.. At some >> point most using shells needed bash, but had as header !#/bin/sh.... >> in the plugin >> >> And we spend time wondering what happened... The point was: They >> needed bash, so they should have #!/bin/bash, not #!/bin/sh... >> >> My point is: Some plugins requrie bash. If we only change the "echo >> -ne" we are still not guraranteed to have any issues for other >> reasons. The way to do it is to tell the developper... Or at least >> make him or her aware of the issue... Not to force him to use a >> particular language or a particular shell. >> >> A tool or a script that transform each using echo -ne, could be made, >> but someone must be responsable of mantaining it... Certainly, if the >> one who wrote the plugin used bash, this would be a requirement for >> his or her plugin. >> >> Soon, though, we will have a model for all plugins when the mathemagix >> plugin becomes the model for all other plugins and the suggested way >> in which plugins should be written and docummented to assure >> portability. >> >> Those are my two cents. >> >> Peace. >> -Adrian. >> >> On Wed, Jul 25, 2012 at 11:16 AM, Sam Liddicott <[email protected]> wrote: >> > He is correct to advocate printf. There is an entry in the bash FAQ in >> > relation to portable programming that endorses his view. >> > >> > Sam >> > >> > On Jul 25, 2012 5:37 PM, "Miguel de Benito Delgado" >> > <[email protected]> wrote: >> >> >> >> Any thoughts on this anyone? I know very little about shell >> >> compatibility issues.. >> >> ________________ >> >> Miguel de Benito. >> >> >> >> >> >> On Mon, Jul 23, 2012 at 6:34 AM, Bernd Losert <[email protected]> >> >> wrote: >> >> > I am not sure if this has been pointed out or not, but a lot of the >> >> > plugin code in src/plugins/*/bin/tm_* uses the echo command in such a >> >> > way that it only works correctly if your shell is bash. I use zsh as >> >> > my shell and when I run something like xypic for example, I always >> >> > get >> >> > these -n when the session starts. To avoid this issue, I suggest >> >> > rewriting anything with echo with printf instead as the behavior of >> >> > printf is the same across *NIX systems, unlike with echo. >> >> > >> >> > -- >> >> > Bernd >> >> > >> >> > _______________________________________________ >> >> > Texmacs-dev mailing list >> >> > [email protected] >> >> > https://lists.gnu.org/mailman/listinfo/texmacs-dev >> >> >> >> _______________________________________________ >> >> Texmacs-dev mailing list >> >> [email protected] >> >> https://lists.gnu.org/mailman/listinfo/texmacs-dev >> > >> > >> > _______________________________________________ >> > Texmacs-dev mailing list >> > [email protected] >> > https://lists.gnu.org/mailman/listinfo/texmacs-dev >> > >> >> _______________________________________________ >> Texmacs-dev mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/texmacs-dev > > > _______________________________________________ > Texmacs-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/texmacs-dev > _______________________________________________ Texmacs-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/texmacs-dev
