Re: announcing bashj

[Eduardo Bustamante]

Thank you for your response Philippe. I'm adding back the mailing lists so
that they can benefit from this response too.


On Tue, Jun 26, 2018 at 5:58 AM, pg  wrote:

>
>
>
> *Thank you, Eduardo, for these remarks... I tried to answer you questions
> - answers in black below. But anyway, may I suggest you to read the
> following links (wiki links), providing a better understanding of what, why
> & how ... ? *
>
>- 
> *http://fil.gonze.org/wikiPG/index.php/Project_bashj_:_a_bash_mutant_with_java_support
>
> *
>- *http://fil.gonze.org/wikiPG/index.php/Bashj_programming_guide
>*
>
>
> On 23/06/18 20:45, Eduardo Bustamante wrote:
>
> On Sat, Jun 23, 2018 at 12:08 PM, pg  
>  wrote:
> [...]
>
> Description: BASHJ - ANNOUNCE TO THE DEVELOPMENT TEAM OF BASH
>
> I am pleased to inform you about bashj - a bash 'mutant' with java
> support.
> This product opens numerous very interesting fields to bash developers.
>
> I have a few questions / comments:
>
> * Under which license / use terms are you releasing bashj? It doesn't
> seem to be free software, the source code does not seem to be
> available in the Sourceforge project, and I can't find any reference
> to the license in the links you shared.   FWIW, I don't have
> enough confidence to test bashj by just downloading a random JAR file
> from the internet and executing it in my computer. I would like to be
> able to inspect the source code and build it myself.
>
> *I am not expert in the choice of licences. I don't care much about that,
> and  when the project was created on sourceforge I chose LGPLv2.1.*
> *Not sure that it is the appropriate one for a mix of bash & java source
> code.*
> *I understand your prudence regarding the jar file.*
> *From version 0.995, the java sources will be available on source forge.*
> *However I want to mention that :*
>
>- *Sources are currently poorly documented*
>- *My coding style is far from the java standards ! Compact code is my
>priority, and I certainly do not approve standards leading to voluminous
>code.*
>- *At this time, I do not want/need source contributors. Remarks, bug
>reports and suggestions are welcome, but I keep driving the code for a
>while.*
>
> * The wiki page recommends creating the installation directory with
> 0777 permissions. That seems a bit too insecure? Why does it need
> world-wide write permissions? (i.e. "sudo mkdir -m=777 /var/lib/bashj/
>   # create the installation directory")
>
>
> *I changed these: *
>
>- *installation target directory is /opt/bashj/*
>- *permission at creation time is set to 0755*
>- *transient files live under /dev/shm/bashj/ *
>
> *But I am not expert in risk detection.*
>
> * What's the motivation behind bashj?  I'm having trouble
> understanding why one would like to use a mixture of Java and bash in
> the same program, when there are options like Jython and Groovy to run
> dynamic scripting languages in the JVM.   Are you using bashj for a
> particular application for which Groovy wasn't apt?
>
>
>
>
>
>
>
>
>
>
>
> *I use bashj for my own projects. Il appreciate the idea of getting access
> to my wide and venerable java personal package library, including servers
> (accessible using memory mapped files). All this from bash, and with an
> impressive speed. I used groovy and was not convinced. Between java and
> python, my preference (laziness?) goes to java. I would like to need no
> more than 2 technologies : java & bash is enough. And what I read about
> jython was not convincing anyway : too heavy. If there is no significant
> public interest for bashj, I will keep using it alone, and remove it from
> source forge. It would be sad, because my experience with it is really
> exciting! *
>
> * Since I haven't run the code (for reasons explained above): How do
> you handle things like the program's current working directory, the
> environment, subshells, controlling terminal, etc. when everything
> seems to run in the same JVM server process?
>
>
>
> *Try it and you'll see how it works. There are some limitations, but AFAIK
> no blocking issues. It is partly discussed in the links provided above. If
> you see significant problems, please let me know. *
>
>
> --
> --
> --
>
> *Philippe Gonze*
> Address: *Rue de la bruyère 12 / 1428 Lillois
> 
> / BE*
> Phone : *00.32.473580758*
> www.gonze.org
> --
> --
>

Re: Directing into a variable doesn't work

[Piotr Grzybowski]

hello,

 I wanted to play around with this idea, and see how it works. Quick and dirty 
patch (against devel@c181950a89c0f0ca4a3ae2480b783da2f7de9565) is attached. 
Just modified parser and hardcoded tempfile /tmp/v_save.bash.temp. result:

bash-5.0$ echo 'hello a' >>> a; echo $a
hello a 

 If you don't mind we can get it off the list, and see if we can workout a 
better way to bind data from redirection with variable, and come up with 
something. If not, maybe you will find something useful in this patch, I have 
no idea if I will be able to present any decent version of it.

cheers,
pg
 



store_result_in_varible_quick_and_dirty.diff.patch
Description: Binary data


On 27 Jun 2018, at 21:03, tetsu...@scope-eye.net wrote:

> 
> 
> When I initially read this thread, I was concerned about the idea of
> adding yet another mutation of the redirect syntax.
> Like how far does this go? Would we introduce a "" someday for
> some other bit of functionality?
> 
> Ideally, I think it would be better if this could be done with pipe
> syntax and builtins
> (so that instead of introducing another redirect syntax for "capture
> to variable",
> we instead pipe to the already-existing "read" command)
> This would also allow for using the built-ins to specify options like
> delimiters, how much to read, allow for reading
> into an array, and so on, and without diving deeper into increasingly
> exotic syntax.
> 
> However adding support for connecting separate pipes to stdout and
> stderr and a generalized version of "lastpipe"
> that can handle multiple builtins within the same job would be a
> pretty big undertaking. It'd probably mean threading
> and thread-safety, and of course some strategy for tying that into job
> control.
> 
> For what it's worth, I think I have a real use case for this proposed
> syntax.
> I'm working on loadable modules to do things like open Unix Domain
> Sockets and so on.
> The general form of these things (so far) is open the file
> descriptors, and then store the FD numbers in a variable.
> I think a better pattern would be "open the file descriptors, and
> write their FD numbers to stdout" - and then capture them.
> Of course in Bash this wouldn't work via command substitution:
> 
> fd=$(connect_to_socket "$socket_path")   # Command subst. is a
> subshell, so file is opened but lost
> 
> However, with a "capture-to-variable" redirect, this pattern would
> work:
> 
> connect_to_socket "$socket_path" >>> socket_fd_var
> 
> More generally, it solves the problem of how to capture output from a
> command that must also modify the
> shell's environment.
> 
> While it's essentially syntactic sugar (and despite my concerns about
> further overloading the redirect operators)
> I think I'm starting to see the value in it.  I can't promise
> anything at this point but I'd like to see what I can come
> up with.
> - Original Message -
> From: chet.ra...@case.edu
> To:"Peter Passchier" , "Martijn Dekker"
> , 
> Cc:
> Sent:Mon, 25 Jun 2018 09:11:45 -0400
> Subject:Re: Directing into a variable doesn't work
> 
> On 6/24/18 11:26 AM, Peter Passchier wrote:
>> Thank you for the feedback, very insightful. Yes, scratch that
> first
>> 'example'. Yay for the here-variable redirection!
> 
> The answer is ultimately the same as it was last month:
> 
> http://lists.gnu.org/archive/html/bug-bash/2018-05/msg00056.html
> 
> (from link:)
> 
> What you're asking for is syntactic sugar for: 
> 
>   some-command > temp-file 
> echo '#' >> temp-file 
> variablename=$(< temp-file) 
> rm -f temp-file 
> variablename=${variablename%?} 
> 
> I would look at a sample implementation, possibly using mmap, if
> someone 
> did one.
> 
>