Eiji
I have tried to write mix task or even generate escript binary file, but it looks like that none of those ways supports some useful shell input methods. I tried to inspect arguments simply with IO.inspect(args)
here-document (<< operator)
A here document is a special-purpose code block. It uses a form of I/O redirection to feed a command list to an interactive program or a command, such as ftp, cat, or the ex text editor.
Source: Here Documents
What I have tried:
# Escript example:
$ ./example --test <<EOL
line 1
line 2
line 3
EOL
["--test"]
# Mix task example:
mix example.demo --test <<EOL
line 1
line 2
line 3
EOL
["--test"]
here-string (<<< operator)
A here string can be considered as a stripped-down form of a here document .
It consists of nothing more than COMMAND <<< $WORD ,
where $WORD is expanded and fed to the stdin of COMMAND .
Source: Here Strings
What I have tried:
# Escript example:
./example --test <<< 5*4
["--test"]
# Mix task example:
mix example.demo --test <<< 5*4
["--test"]
Maybe I need to compile Erlang with some extra flags or maybe it’s just not supported at all?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
NobbZ
Heredocs/-strings are written to stdin of your application, but from the output you show, it seems as if you only inspect parsed options.
foo <<< baris just syntactic sugar forecho bar | foo, while<<is (roughly) equivalent toecho "l1\nl2\nl3\n" | foo.Eiji
To new project I have only added:
a)
escriptoption inprojectfunction:b) Replaced
lib/example.exto shortest form:c) and finally added mix task with also minimal code:
Not sure what exactly you mean by
parsedoptions. As you can see I’m not usingOptionParser- I’m just trying to debug everything I got inargs.NobbZ
Okay, you are not using
OptionParserbut that doesn’t matter, you are inspecting the wrong thing as I said already.You need to read
stdin.alco
Here-docs are handled by your shell. As NobbZ explained, the content of a here-doc is passed on the standard input stream to the program. Try this example:
Eiji
Ah, now I can see … However there is one problem with this solution.
Of course we can check it like this:
but what to do if user by mistake will not pass
<<operator?In my opinion expected behavior (for app - not for
) here would be raise describing problem, but I’m not sure how I could make a check for using
IO.read/2<<operator … I do not even see an option for setting timeout in documentation (at least not forIO.read/2which means it will collect input until user would terminate app, right?Note: Of course I could use
\n, but it’s extra requirement for end-user - not really problem for me.NobbZ
No program will ever see
<<except for the shell, which then does some magic to turn it into the started programsstdin.This is by design.
If
--testoption expects further data fromstdindocument as such in your programs manual, if it does not, then do not try to dostdinmagic.alco
My code snippet was meant to demonstrate how a here-document’s content is passed on the standard input to the program. I wasn’t proposing a solution because I don’t know the requirements of what you’re trying to achieve.
If you want your program to take user input which may span more than one line, you may want to read the input one line at a time and stop upon encountering an empty line. Alternatively, using
IO.read(:stdio, :all)is also fine, in my opinion. It reads everything up to the end of input which can be signaled in several different ways.When a program is invoked in a shell, users should know that they can signal the end of input by pressing Ctrl-D on an empty line. This is just a way to let the shell know there won’t be any more input from the user, so that it can close the input pipe connected to the running program at which point the running program will encounter the EOF/end-of-input if it’s reading from stdin.
The same outcome can be achieved by using shell pipes:
or by using shell’s stream redirection to read from a file:
If you’re still looking for help, then I’d like to ask you to rephrase your question because the way it’s currently formulated doesn’t explain what the actual problem you’re trying to solve is.
Eiji
I was just looking if there is any way to pass multi line argument value instead of using
\nor\character at end of each line which are not handy and requires to pass/edit data manually. I have found suchhere-*syntactic sugar inBASHNotice that here we have only prefix
--test << EOFand suffixEOFfor such value i.e. value is not changed and it could be just copied. Single line have only prefix (--test), but it’s much easier that other solutions. Simple example of use case here is multi lineJSONparsing, so end-user could use such option by simply copyingJSONdata - without any need to replace new line with\nor adding\at end of each data line (just imagine huge prettifiedJSON).NobbZ
Have you tried this:
Eiji
I wonder how I could forget about so simple way.

It’s always darkest before dawn.