Bug 1051295 - non interactive use of yast seems currently broken
Summary: non interactive use of yast seems currently broken
Status: RESOLVED DUPLICATE of bug 966042
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2 (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: Jiri Srain
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-28 19:01 UTC by Roger Whittaker
Modified: 2017-08-04 12:09 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Whittaker 2017-07-28 19:01:36 UTC
seen in 20170725 with yast2-3.3.4-1.1.x86_64

For example:

# yast lan help

YaST Configuration Module lan
------------------------------

Network Card Configuration

Basic Syntax:
    yast2 lan interactive
    yast2 lan <command> [verbose] [options]
    yast2 lan help
    yast2 lan longhelp
    yast2 lan xmlhelp
    yast2 lan <command> help

Commands:
    add     Add a network card
    delete  Delete a network card
    edit    Change existing configuration
    list    Display configuration summary
    show    Display configuration summary

Run 'yast2 lan <command> help' for a list of available options.

Warning: unable to close filehandle properly: Bad file descriptor, <STDIN> line
        21 during global destruction (#1)
    (S io) There were errors during the implicit close() done on a filehandle
    when its reference count reached zero while it was still open, e.g.:

        {
            open my $fh, '>', $file  or die "open: '$file': $!\n";
            print $fh $data or die "print: $!";
        } # implicit close here

    Because various errors may only be detected by close() (e.g. buffering could
    allow the print in this example to return true even when the disk is full),
    it is dangerous to ignore its result. So when it happens implicitly, perl will
    signal errors by warning.

    Prior to version 5.22.0, perl ignored such errors, so the common idiom shown
    above was liable to cause silent data loss.
Comment 1 Steffen Winterfeldt 2017-07-31 12:31:45 UTC
Josef, an idea?
Comment 2 Josef Reidinger 2017-07-31 12:44:42 UTC
Can you please provide yast logs from some real example?

In your output you use lan help which is correct result ( of course that perl warning is annoying ). So can you show example when it is broken and please attach yast logs for that example, so we can see where exactly it is broken. Thanks


Steffen - I strace this warning and it looks like it comes from ag_tty. So I suggest to ask mvidner, if he have clue.

ag_tty - https://github.com/yast/yast-yast2/blob/master/library/commandline/src/servers_non_y2/ag_tty#L85
Comment 3 Steffen Winterfeldt 2017-07-31 13:26:41 UTC
Thanks, Josef!

Martin, how do we get rid of this perl warning?
Comment 4 Roger Whittaker 2017-08-01 16:30:05 UTC
Replying to comment#2 - I accept that it isn't really broken - it's just emitting some irritating errors.  I successfully configured an interface with it.
Comment 5 Josef Reidinger 2017-08-02 11:52:46 UTC
(In reply to Roger Whittaker from comment #4)
> Replying to comment#2 - I accept that it isn't really broken - it's just
> emitting some irritating errors.  I successfully configured an interface
> with it.

OK, thanks for confirmation. So not so severe, but really annoying.
Comment 6 Ladislav Slezák 2017-08-04 12:09:05 UTC
Already reported in bug 966042.

The workaround is to set PERL_RL=Perl, e.g. run "PERL_RL=Perl yast lan help".

*** This bug has been marked as a duplicate of bug 966042 ***