# 9.0 dialog and it's STDIN



## Seeker (Feb 21, 2012)

In target port, this presents a dialog:
`# /usr/bin/make config`

Instead via keyboard, I want to send ENTER key to dialog (piped to STDIN of above cmd):

```
#!/bin/sh

# ENTER confirms and closes dialog
echo 'CODE_HERE' | /usr/bin/make config
```


----------



## phoenix (Feb 21, 2012)

If you only want to send enter, meaning accept the default options, then the command-line is:
`# make -DBATCH install clean`

Or, if you prefer to be verbose:
`# make BATCH=yes install clean`


----------



## Seeker (Feb 21, 2012)

I see, but what if a sequence is a little bit more complex?
Send it:
Button down
Space
Enter

This would [de]select second option and confirm


----------



## wblock@ (Feb 21, 2012)

When you say "target port", do you mean a FreeBSD port?  Options can be enabled by setting the WITH_ or WITHOUT_ values:

```
# cd /usr/ports/x11-servers/xorg-server
# make -DWITHOUT_HAL install clean
```

Might need to combine that with BATCH as phoenix shows to prevent the options dialog from appearing.


----------



## Seeker (Feb 21, 2012)

Yes, FreeBSD port, those in /usr/ports/* tree

It is NOT a point of specifying variables to make or finding alternative solutions, BUT *automated interaction with 9.0's dialog via STDIN*, (changed from keyboard).

So, `#  cd ... | make config`


----------



## kpa (Feb 21, 2012)

Such automation by feeding the dialog "command codes" via stdin doesn't work, the problem is that the dialog program expects an stdin that it can handle in "raw" mode and process the keystrokes unbuffered, a pipe certainly does not qualify as such input.


----------



## Seeker (Feb 21, 2012)

I'm not an expert on this, so I am having hard times understanding you.


> ... *"raw" mode* and process the keystrokes *unbuffered* ...


How does it differ from pipe?!
Is there some other kind of piping
Seems as there are other ways for STDIN, to receive data.
Can it be mimicked?


----------



## kpa (Feb 21, 2012)

The "raw" mode means that the application receives the keystroke as soon as you press a key and it can process each keystroke indidually. The opposite of this is the way input usually works, you type something and end it with enter, the application will not receive any input until you've pressed the enter key.


----------



## Seeker (Feb 21, 2012)

I see now. Thanks.

My aim is to just set a default preselected options (no build, install, or anything else).
This is the *only* target:
[CMD="make"]config[/CMD]
I've tried with both *-DBATCH* and *BATCH=yes* and nada
When this succeeds, I'll send prompt which goes to STDOUT to /dev/null
Idea, anyone?


----------



## kpa (Feb 21, 2012)

Set BATCH in the environment

`# env BATCH=1 make whatever`


----------



## Seeker (Feb 21, 2012)

kpa said:
			
		

> Set BATCH in the environment
> 
> `# env BATCH=1 make whatever`



That doesn't work either

```
#!/bin/sh

env BATCH=1 /usr/bin/make config
```
Dialog hangs ..., until I press ESC or ENTER


----------



## phoenix (Feb 21, 2012)

You're trying to solve the wrong problem.  

The problem you are trying to solve is "how do I manipulate the OPTIONS dialog automatically by sending keystrokes to libdialog".

The correct problem description is "how do I pre-set OPTIONS for a port so that I don't have to muck around with the OPTIONS dialog".

And the solution to that is, read the Makefile, find the OPTIONS section, figure out the name of the variables, then set either *WITH_VARNAME* (enable) or *WITHOUT_VARNAME* (disable) for each of the variables.  To set them only once, you specify them on the command-line as options to make:
`# cd /usr/ports/whatever; make -DWITH_VAR1 -DWITH_VAR2 -DWITHOUT_VAR3 ... install clean`

To set them permanently, store them in /var/db/ports/<portname>/options, which can be determined for any port like so:
`# make -C /usr/ports/whatever/name -V OPTIONSFILE`


----------



## Seeker (Feb 21, 2012)

phoenix said:
			
		

> You're trying to solve the wrong problem.


Am I? 

Nope ...


			
				phoenix said:
			
		

> The problem you are trying to solve is "how do I manipulate the OPTIONS dialog automatically by sending keystrokes to libdialog".
> 
> The correct problem description is "how do I pre-set OPTIONS for a port so that I don't have to muck around with the OPTIONS dialog".
> 
> ...


What I want to do is to ensure that if a port doesn't have its options set (options file in /var/db/ports/<portname>/options doesn't exist), THEN just send ENTER to dialog to set default options.
Simple as that and I had a way to do that until 9.0, by sending letter 'o' to dialog.

```
cd_die /usr/ports/"$1" 

    # Auto set to default options
    # DON'T indent it!
    # Send key 'o' to dialog and quiet it, as we don't wana see dialog
qcmd "$make" config <<MyEND
o
MyEND
```

Now in 9.0 I have a problem, as it takes ENTER for confirmation and it simply doesn't work!


----------



## phoenix (Feb 21, 2012)

If there are no options set (options file not present), then go with the defaults by adding *-DBATCH* to the make command-line.  That way, you won't even see the OPTIONS dialog appear at all.

So, you do a check for the options file, and conditionally add *-DBATCH* to the command-line.


----------



## Seeker (Feb 21, 2012)

phoenix said:
			
		

> If there are no options set (options file not present), then go with the defaults by adding *-DBATCH* to the make command-line.  That way, you won't even see the OPTIONS dialog appear at all.
> 
> So, you do a check for the options file, and conditionally add *-DBATCH* to the command-line.


That is not true, as I already replied to *kpa*.
Dialog appeared anyway.


----------



## kpa (Feb 22, 2012)

Of course the dialog appears because you're instructing the dialog to open unconditionally with make config. The proper way to make use of BATCH is to use it with `# make install`.
For example:

`# env BATCH=1 make -C /usr/ports/www/chromium install clean`

No dialogs and the default options are selected and saved automatically.


----------



## Seeker (Feb 22, 2012)

That doesn't meet my req: no build, install, or anything else, just config target.
Why did my sh code worked in 8.X?


----------



## phoenix (Feb 22, 2012)

Different versions of libdialog.

What, exactly, are you wanting to do? Why do you need to 'just config' a port, without installing it?


----------



## Seeker (Feb 22, 2012)

If a port doesn't have its options set (options file in /var/db/ports/<portname>/options doesn't exist), THEN accept default pre-selected port's options, which creates: options file in /var/db/ports/<portname>/options.


----------



## kpa (Feb 22, 2012)

We get that part but why do you have to do it befofe compiling and installing a port?


----------



## Seeker (Feb 22, 2012)

Answering to that, is to open portal of never ending chatter.
I prefer to focus on 1 single problem. That is why I opened this thread.

In short, part of my script -> function (whose relevant code I've already posted), must be made to also work on 9.0
Change of dialog in 9.0 is preventing that.


----------



## aragon (Feb 22, 2012)

`# DIALOG=true make config`


----------



## phoenix (Feb 22, 2012)

And we're asking why you think it needs to be done separately.


----------



## Seeker (Feb 22, 2012)

aragon said:
			
		

> `# DIALOG=true make config`


Yours shoot is a closest one ...
However it sets ALL options to *WITHOUT_*=true*, which ISN'T *accepted default pre-selected port's options*

Example: (for clementine)

Your method:

```
WITHOUT_VISUALISATION=true
WITHOUT_LASTFM=true
WITHOUT_GPOD=true
WITHOUT_MTP=true
```


Default: (ENTER passed to dialog)

```
WITHOUT_VISUALISATION=true
WITH_LASTFM=true
WITH_GPOD=true
WITH_MTP=true
```


----------



## Seeker (Feb 23, 2012)

aragon said:
			
		

> `# DIALOG=true make config`


Additionally ..., could you tell me where is it documented?


----------



## Seeker (Feb 23, 2012)

phoenix said:
			
		

> And we're asking why you think it needs to be done separately.


It doesn't need to be done separately for regular ports use.
My script needs it, as it does other more complex things!
And this is just an initial stage in config process.
But I could go on and on ...

Can we now finally solve this problem?


----------



## aragon (Feb 23, 2012)

Seeker said:
			
		

> However it sets ALL options to *WITHOUT_*=true*, which ISN'T *accepted default pre-selected port's options*


Ah, hmm, yes.



			
				Seeker said:
			
		

> Additionally ..., could you tell me where is it documented?


Use the source, Luke... specifically /usr/ports/Mk/bsd.port.mk, line 6010.

There's still hope, but you'll probably need to write your own script to stand-in for dialog, that mimics its behaviour for your own purposes.  Then set the DIALOG variable to your script's path.


----------



## Seeker (Feb 23, 2012)

I'm having a hard time understanding make's syntax.
Is that a this line?

```
DEFOPTIONS="$${DEFOPTIONS} $$1 \"$$2\" $${val}"; \
```

What did you meant by "*script to stand-in for dialog*"?
I think you meant script, which REPLACES dialog and it is being called via DIALOG=/my_script.sh

But how should it replace it.

DUH!
I can't believe through what I must go, JUST because I can't pipe ENTER to god damn dialog!


----------



## jalla (Feb 23, 2012)

lang/expect?


----------



## phoenix (Feb 23, 2012)

Seeker said:
			
		

> I can't believe through what I must go, JUST because I can't pipe ENTER to god damn dialog!



I still say you're trying to solve the wrong problem.

If all you need to do is put the default options into /var/db/ports/<portname>/options, then just pull them out of the Makefile for the port.  They are all listed in in the *OPTIONS* variable.  You can probably even use the code in /usr/ports/Mk/bsd.port.mk to do it.

To me, it just seems wrong to use a screen-scraper thingy to work around an API issue.  It's like trying to use a screen macro setup to click buttons on a web page instead of just submitting GET/POST requests to the server.


----------



## kpa (Feb 24, 2012)

This is probably what you want or close to it.


```
$  make -C /usr/ports/www/firefox showconfig
===> The following configuration options are available for firefox-10.0.2,1:
     DBUS=on (default) "Enable D-BUS support"
     PGO=off (default) "Enable Profile-Guided Optimization"
     DEBUG=off (default) "Build a debugging image"
     LOGGING=off (default) "Enable additional log messages"
     OPTIMIZED_CFLAGS=off (default) "Enable some additional optimizations"
===> Use 'make config' to modify these settings
```

What I would do is to first delete any existing settings for the port in /var/db/ports with `# make rmconfig` and run the above and parse the default values from the output.


----------



## Seeker (Feb 24, 2012)

kpa said:
			
		

> What I would do is to first delete any existing settings for the port in /var/db/ports with `# make rmconfig`


Nope! Because, my script kicks in, with mentioned function *IF IT DETECTS*, that options file *doesn't exist* for target port.


			
				kpa said:
			
		

> and run the above and parse the default values from the output.


Parsing = using grep, sed, awk, ...
You are making me into *string manipulation*.

I really prefer to JUST send *one* god damn ENTER key to dialog!
And just 15 min ago I SUCCEEDED! HELL YEA! 
Solution was to use:


			
				jalla said:
			
		

> lang/expect?


----------



## Seeker (Feb 24, 2012)

phoenix said:
			
		

> To me, it just seems wrong to use a screen-scraper thingy to work around an API issue.  It's like trying to use a screen macro setup to click buttons on a web page instead of just submitting GET/POST requests to the server.


Could you please define "_screen-scraper thingy_"


----------



## wblock@ (Feb 24, 2012)

Expect == "screen-scraper thingy".  It reads the contents of a screen or other text input.  Sometimes required, but inelegant.


----------



## phoenix (Feb 24, 2012)

Seeker said:
			
		

> Could you please define "_screen-scraper thingy_"



Where you show something on the screen, then run some kind of macro, screen-recorder, or whatnot to send mouse movements, mouse clicks, keyboard events to move the cursor around on the screen, and activate elements on the screen.  It's the least elegant, worst way to do anything, especially when there are APIs available for directly manipulating the data via a script/program.

There are plenty of ways to set/manipulate the OPTIONS for a port without ever showing anything onscreen (via APIs).

Sending keyboard events to a dialog onscreen is a "screen-scraper thingy".  It's extremely fragile.  Any change to the layout of the screen, or the way events occur onscreen, and the "screen-scraper thingy" breaks (as you discovered).

If you had written your script from the get-go using the ports APIs, then nothing would have changed, and your script would still be working.


----------



## Seeker (Feb 24, 2012)

For me, OCR is "*screen-scraper* thingy".
Expect sends *ALL dialog's output*, to /dev/null, so not only that there is *no screen-scraper parsing*, there is *no even string parsing*!
It just SENDS *1 newline* to dialog and game over!


----------

