Re: Bash handling of ENOENT on missing files and directories
On 11/09/17 20:58, Bob Proulx wrote: Jonny Grant wrote: Greg Wooledge wrote: The wording is taken directly from perror() and related library calls, as translated for your locale. Yes, it's a known limitation of POSIX that it uses a shared error code for both files and directors, ENOENT. Which without programmers handling and checking the stat() flags, means the error isn't completely clear in the case where a file or dir does exist. I don't see how POSIX is involved in this. Blaming POSIX is a complete non-sequitur here. Why do you feel it isn't? I imagine we have spoken already for longer about this, than it would have been to fix it. I see no bug to fix here. However I fear that trying to fix an imaginary one would introduce a bug here. How can an easy update to clarify message "No such file or directory" introduce a bug? Jonny
Re: Question
Dear Bob I use Linux. My business to provide services for problems that I solve, as you mention, by calling Awk, sed, join, etc., and databases. I allow my customers to login to a box that I provide in my datacenter. I cannot accept that it is impossible to restrict them to only call my *,sh scripts. I found a company that has a nice obfuscating and encrypting product for shell script, and I am trying it. I am no worried only about passwords, but the overall logic itself. Many thanks for the time you took to respond. But in this case you fall close to an error. The market needs a tool so we can generate solutions and also protect our intellectual property. I am not smart enough to write it, but somebody will. Yours Federico On Mon, Sep 11, 2017 at 2:54 PM, Bob Proulx wrote: > Saint Michael wrote: > > Dear Maintainer > > Note that I am not the maintainer. > > > Is there a commercial or free software that can take a Bash script and > > transparently turn it into a C executable, provided the machines where it > > runs has any of the external commands like awk, etc? > > Not as far as I am aware. And since no one else has spoken up with a > suggestion then I assume not. > > > Something like a Java virtual machine, for Shell. > > Yes. That already exists! It is the bash shell interpreter itself. > If you install a JVM then it can interpret Java programs. If you > install bash then it can interpret bash programs. Same thing. > > The underlying issue is that shells are by design mostly there to > invoke external programs. Therefore most of the activity of the shell > is to run other programs such as awk, grep, sed, and so forth. It > isn't enough to have only the bash program but also the entire set of > other programs that is invoked. Java by comparison can also execute > external programs but since that is not the primary design goal of it > most Java programs do not spend 99% of their code doing so. > > > I think this language is powerful and I want to distribute some > > tools that contain critical information. > > > > So far I have been googling and there is only obfuscation tools, not > > compilation tools. > > Making a shell script compiler would be a very hard problem because > the shell is an interpretive language with a primary task of invoking > external programs. It would be very, very hard. Impossible actually. > The nature of interpretive languages are that they can do things that > compiled languages cannot do. For example interpreted programs can > generate code on the fly and interpret it. Such as creating functions > during runtime. Such as dynamically creating and executing code based > upon dynamic input. Such tasks are easily done using an interpreted > language but must be done differently when using a compiled language. > One cannot create a compiler that can compile every capability of an > interpreted language without itself embedding an interpreter for that > language. > > If you restrict an interpretive language down to only features that > can be compiled then it is always possible to write a compiler for it. > But then it is for a restricted set of language features as compared > to the original language. It is a different language. Sometimes this > is an acceptable tradeoff. But I will hazard a guess that for the > shell and for programs written for it this would be a quite different > language and no longer useful. Possible. But not useful. > > > I think this language is powerful and I want to distribute some > > tools that contain critical information. > > You don't say what critical information you are talking about. But it > makes me think things like accounts and passwords that you would not > want to be available in clear text. Note that obfuscating them in a > compiled program does not make them inaccessible. > > You also don't say which OS you are using. Most of us here will > probably be using a GNU/Linux distribution which includes the shell > natively or the Apple Mac which includes a working environment. > Therefore I will assume you are using MS-Windows. I suggest either > bundling an entire environment such as MinGW such as Bash for Windows > or Cygwin so that all of your external dependencies are satisfied. > Or using a different language such as C which is natively compiled. > Or using a restricted set of Perl, Python, Ruby, or other that already > has a compiler available for that restricted subset. > > Bob >
Re: Question
Saint Michael wrote: > Dear Maintainer Note that I am not the maintainer. > Is there a commercial or free software that can take a Bash script and > transparently turn it into a C executable, provided the machines where it > runs has any of the external commands like awk, etc? Not as far as I am aware. And since no one else has spoken up with a suggestion then I assume not. > Something like a Java virtual machine, for Shell. Yes. That already exists! It is the bash shell interpreter itself. If you install a JVM then it can interpret Java programs. If you install bash then it can interpret bash programs. Same thing. The underlying issue is that shells are by design mostly there to invoke external programs. Therefore most of the activity of the shell is to run other programs such as awk, grep, sed, and so forth. It isn't enough to have only the bash program but also the entire set of other programs that is invoked. Java by comparison can also execute external programs but since that is not the primary design goal of it most Java programs do not spend 99% of their code doing so. > I think this language is powerful and I want to distribute some > tools that contain critical information. > > So far I have been googling and there is only obfuscation tools, not > compilation tools. Making a shell script compiler would be a very hard problem because the shell is an interpretive language with a primary task of invoking external programs. It would be very, very hard. Impossible actually. The nature of interpretive languages are that they can do things that compiled languages cannot do. For example interpreted programs can generate code on the fly and interpret it. Such as creating functions during runtime. Such as dynamically creating and executing code based upon dynamic input. Such tasks are easily done using an interpreted language but must be done differently when using a compiled language. One cannot create a compiler that can compile every capability of an interpreted language without itself embedding an interpreter for that language. If you restrict an interpretive language down to only features that can be compiled then it is always possible to write a compiler for it. But then it is for a restricted set of language features as compared to the original language. It is a different language. Sometimes this is an acceptable tradeoff. But I will hazard a guess that for the shell and for programs written for it this would be a quite different language and no longer useful. Possible. But not useful. > I think this language is powerful and I want to distribute some > tools that contain critical information. You don't say what critical information you are talking about. But it makes me think things like accounts and passwords that you would not want to be available in clear text. Note that obfuscating them in a compiled program does not make them inaccessible. You also don't say which OS you are using. Most of us here will probably be using a GNU/Linux distribution which includes the shell natively or the Apple Mac which includes a working environment. Therefore I will assume you are using MS-Windows. I suggest either bundling an entire environment such as MinGW such as Bash for Windows or Cygwin so that all of your external dependencies are satisfied. Or using a different language such as C which is natively compiled. Or using a restricted set of Perl, Python, Ruby, or other that already has a compiler available for that restricted subset. Bob
Re: Bash handling of ENOENT on missing files and directories
Jonny Grant wrote: > Greg Wooledge wrote: > > The wording is taken directly from perror() and related library calls, > > as translated for your locale. > > Yes, it's a known limitation of POSIX that it uses a shared error code for > both files and directors, ENOENT. Which without programmers handling and > checking the stat() flags, means the error isn't completely clear in the > case where a file or dir does exist. I don't see how POSIX is involved in this. Blaming POSIX is a complete non-sequitur here. > I imagine we have spoken already for longer about this, than it would have > been to fix it. I see no bug to fix here. However I fear that trying to fix an imaginary one would introduce a bug here. Bob
Re: History expansion quoting problem
Chet Ramey wrote: > On 9/8/17 4:18 AM, Philipp Sasse wrote: > > Executing something like > > echo "foo > > bar" | sed '/foo/!d' > > results in an error. Apparently the history expansion considers only > > quoting characters on the same input line, so the closing double quote is > > taken as opening double quote, escaping the following single quotes, thus > > these don't escape the ! anymore. > History expansion is explicitly line-oriented, and always has been. If you say so. But it is nevertheless a highly unexpected and annoying behavior. > There's > not a clean way to make it aware of the shell's current quoting state I didn't look at the code, I just know it works in zsh. At least, the man page Should reflect this behavior, don't you think so? Should I write a patch for the man page? Best regards, Philipp. Testo Visual Systems GmbH, Sitz Titisee, Celsiusstraße 2, 79822 Titisee-Neustadt Handelsregister Freiburg HRB 712427 USt.IdNr. DE 297941089 Geschäftsführer: Dr. Rolf Merte, Patrick Zahn
