9.0 dialog and it's STDIN

[Seeker]

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]

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

Ah, hmm, yes.

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]

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]

lang/expect?

 

[phoenix]

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]

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]

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.

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:

lang/expect?

 

[Seeker]

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@]

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

 

[phoenix]

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]

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!