[Bug-wget] [bug #54178] wget sometimes returns 1024

[J]

URL:
<http://savannah.gnu.org/bugs/?54178>

Summary: wget sometimes returns 1024
Project: GNU Wget
Submitted by: now3d
Submitted on: Sun 24 Jun 2018 06:48:09 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: None
Operating System: None
Reproducibility: None
Fixed Release: None
Planned Release: None
Regression: None
Work Required: None
Patch Included: None

_______________________________________________________

Details:

When wget can't connect to a server, it would appear it is returning 1024 to
bash. Note the site exists, but has no web server, shouldn't wget retur (0)
for success and (1) for an error?

--2018-06-24 15:29:32-- http://beflirty.com/
Resolving beflirty.com (beflirty.com)... failed: Name or service not known.
wget: unable to resolve host address ‘beflirty.com’





_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[J]

Follow-up Comment #1, bug #54178 (project wget):

$ wget --version
GNU Wget 1.19.4 built on linux-gnu.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Tim Ruehsen]

Follow-up Comment #2, bug #54178 (project wget):

$ wget http://beflirty.com/
--2018-06-24 21:08:30-- http://beflirty.com/
Resolving beflirty.com (beflirty.com)... failed: Name or service not known.
wget: unable to resolve host address 'beflirty.com'
$ echo $?
4

See 'man wget' (section EXIT STATUS). 4 is a network failure.

Maybe you can give some more details on how to reproduce 1024.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dale Worley]

Follow-up Comment #3, bug #54178 (project wget):

The reported status of 1024 is suspiciously equal to the documented status of
4, shifted up 8 bits.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[J]

Follow-up Comment #4, bug #54178 (project wget):

Hi
I've attached C code example which invokes "wget". I think you are right, the
system() syscall invokes a shell, which invokes wget.. that seems to fork()
which is probably why the result is shifted 8bits

(file #44468)
_______________________________________________________

Additional Item Attachment:

File name: wget2.c Size:0 KB


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dale Worley]

Follow-up Comment #5, bug #54178 (project wget):

Looking at the manual page for system(3) on my system:

RETURN VALUE
The value returned is -1 on error (e.g., fork(2) failed), and
the
return status of the command otherwise. This latter return status
is
in the format specified in wait(2). Thus, the exit code of the
command
will be WEXITSTATUS(status). In case /bin/sh could not be
executed,
the exit status will be that of a command that does exit(127).

Looking at the manual page for wait(2) on my system:

WEXITSTATUS(status)
returns the exit status of the child. This consists of
the
least significant 8 bits of the status argument that the
child
specified in a call to exit(3) or _exit(2) or as the
argument
for a return statement in main(). This macro should be
employed
only if WIFEXITED returned true.

Blindly searching through the system *.h files, it appears that, effectively,

#define WEXITSTATUS(status) (((status) & 0xff00) >> 8)

This suggests that if you want to print the subprocess's exit status, you need
to change the printf in wget2.c to:

printf("wget result: %d\n", WEXITSTATUS(result));

The value of result as an integer isn't fixed by the specification of
system(3), only the value of WEXITSTATUS(result).


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[J]

Follow-up Comment #6, bug #54178 (project wget):

Hi David

Thank you for you message, I will use WEXITSTATUS(result) as you describe.

BTW, I noticed my Ubuntu LTS machine man page for system(3) looks quite
different from yours. I wonder if you are not running GNU/Linux?


RETURN VALUE
The return value of system() is one of the following:

* If command is NULL, then a nonzero value if a shell is available,
or
0 if no shell is available.

* If a child process could not be created, or its status could not
be
retrieved, the return value is -1.

* If a shell could not be executed in the child process, then
the
return value is as though the child shell terminated by
calling
_exit(2) with the status 127.

* If all system calls succeed, then the return value is the
termina‐
tion status of the child shell used to execute command. (The
termi‐
nation status of a shell is the termination status of the last
com‐
mand it executes.)

In the last two cases, the return value is a "wait status" that can
be
examined using the macros described in waitpid(2). (i.e.,
WIFEXITED(),
WEXITSTATUS(), and so on).

system() does not affect the wait status of any other children.


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Dale Worley]

Follow-up Comment #7, bug #54178 (project wget):

I'm running Fedora 19.

In any case, the critical part, "In the last two cases, the return value is a
"wait status" that can be examined using the macros described in waitpid(2).
(i.e., WIFEXITED(), WEXITSTATUS(), and so on)." seems to be functionally the
same between your system and mine.


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[J]

Follow-up Comment #8, bug #54178 (project wget):

Thank you for your reply

ok, let's close this ticket. Not sure how to do that though.

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[Tim Ruehsen]

Update of bug #54178 (project wget):

Status: None => Inspected
Open/Closed: Open => Closed


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?54178>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/