Re: [gentoo-user] OT scripting - strip zero if between period and digit

2019-01-21 Thread François-Xavier CARTON

Le 22/01/2019 à 03:05, François-Xavier CARTON a écrit :

Le 22/01/2019 à 00:50, Adam Carter a écrit :
I need to clean up a file which has IP addresses with leading zeros in 
some of the octets so I need to make, say, .09 into .9


How do i do that in sed/awk/whatever?



I believe that should do:

sed 's/0*\([0-9]\)/\1/g'

eg.

$ sed 's/0*\([0-9]\)/\1/g' <

My bad, it should be:

sed 's/0*\([0-9][0-9]*\)/\1/g'

(tests are indeed needed!)

François-Xavier



Re: [gentoo-user] OT scripting - strip zero if between period and digit

2019-01-21 Thread François-Xavier CARTON

Le 22/01/2019 à 00:50, Adam Carter a écrit :
I need to clean up a file which has IP addresses with leading zeros in 
some of the octets so I need to make, say, .09 into .9


How do i do that in sed/awk/whatever?



I believe that should do:

sed 's/0*\([0-9]\)/\1/g'

eg.

$ sed 's/0*\([0-9]\)/\1/g' <

Re: [gentoo-user] OT scripting - strip zero if between period and digit

2019-01-21 Thread Andrew Udvare
On 21/01/2019 18:50, Adam Carter wrote:
> I need to clean up a file which has IP addresses with leading zeros in
> some of the octets so I need to make, say, .09 into .9
> 
> How do i do that in sed/awk/whatever?

A regex would be difficult. Parser is what you want.

You could use Python's ipaddress module (Python 3.3+). It will fix your
IPs (below is all one line):

python -c $'import ipaddress, sys;\nfor x in sys.argv[1:]:
print(ipaddress.ip_address(x))' 1.02.3.4 001.002.003.004

Output:
1.2.3.4
1.2.3.4

Fix that for stdin:

python -c $'import ipaddress, sys;\nfor x in sys.stdin.readlines():
print(ipaddress.ip_address(x.strip()))' <<< $'1.02.3.4\n001.002.003.004'

That way you can do:

python -c $'import ipaddress, sys;\nfor x in sys.stdin.readlines():
print(ipaddress.ip_address(x.strip()))' < list-of-ip-addresses

I'm sure there's a nicer way with modules installed with other languages
but this is built into Python as of version 3.3.

Andrew



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] OT scripting - strip zero if between period and digit

2019-01-21 Thread Grant Taylor

On 1/21/19 5:02 PM, Michael Orlitzky wrote:

You need a parser, not a regular expression.


The first thing that came to mind is splitting the values and passing 
them through printf.


(You can do it with a regex, but it's going to be one of those comical 
twelve-page-long things.)


I don't know about 12 pages.  But, yes, a regular expression that takes 
all the possible cases into account, especially as the four octet IP, 
will be … complicated.  A regular expression to work on an individual 
octet might be less complicated.


You can play with REs fairly easily via sed.



Re: [gentoo-user] OT scripting - strip zero if between period and digit

2019-01-21 Thread Michael Orlitzky

On 1/21/19 6:50 PM, Adam Carter wrote:
I need to clean up a file which has IP addresses with leading zeros in 
some of the octets so I need to make, say, .09 into .9


How do i do that in sed/awk/whatever?


The first thing you should do is construct a bunch of test cases, with 
all of the possible input representations and what you think the output 
representation should be. Then, you should write a program in something 
other than bash that passes all of the test cases. It's not as easy as 
it sounds; for example:


  * What happens to 0.1.2.3?

  * What happens to 01.2.3.4?

  * What happens to 1.2.3.0?

  * What happens to 1.2.000.3?

You need a parser, not a regular expression. (You can do it with a 
regex, but it's going to be one of those comical twelve-page-long things.)




[gentoo-user] OT scripting - strip zero if between period and digit

2019-01-21 Thread Adam Carter
I need to clean up a file which has IP addresses with leading zeros in some
of the octets so I need to make, say, .09 into .9

How do i do that in sed/awk/whatever?


[gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Nikos Chantziaras

On 21/01/2019 20:25, Jacques Montier wrote:
Le lun. 21 janv. 2019 à 19:04, Nikos Chantziaras > a écrit :


I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say
that you should first find out what command is being executed with
sudo.
To do that, try to emerge bash, and when the sudo prompt pops up,
switch
to another terminal window and do:

    ps aux | grep sudo

What's the output of that?

ps aux | grep sudo
267:root     19845  0.0  0.0  54260  4304 pts/0    S+   19:23   0:00 
sudo eix-update


Well, something is trying to execute a "sudo eix-update". The bash 
ebuild certainly doesn't, so you should check your installation for any 
weird scripts or aliases you might be using. A grep on /etc for 
"eix-update" might also reveal something:


  grep -r eix-update /etc

And also check your env and aliases:

  which emerge
  alias | grep emerge
  env | grep eix

These are general hints on where to look, since I have no clue myself as 
to why an "emerge -uv bash" would ever try and execute "sudo 
eix-update", so it seems you have digging to do.





Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jack

On 2019.01.21 13:41, Jacques Montier wrote:
Le lun. 21 janv. 2019 à 19:19, Jack   
a

écrit :

>
> I have a suspicion that this really might be sandbox related.
> /dev/fd/whatever are all in the live system, and if I understand
> correctly, emerge works within the sandbox, so you should not be  
able
> to get at those files (certainly not write to them, but it isn't  
clear

> what the ebuild is trying to do there.)
>
> However, if you are running the emerge (please do clarify that your  
are
> trying to emerge bash, not just manually build it) as root, I don't  
see

> any reason it should try to use sudo for anything.
>
> Just for a change, try logging in as root, not doing su, and see if  
the

> emerge works.
>
> Jack
>

Jack,
- I don't manually build bash. Just : #emerge bash
- CTRL+Alt+F1 to get out of X and go to TTY1
- logged as root with the root password
- emerge bash stops at password required.
Since you are logged in as root, have you tried the root password when  
sudo asks?  I wonder if it's looking for the portage password, which I  
don't think exists.  As someone else said - there is really no reason  
for sudo to be used if you are root.  However, during the emerge, I  
believe the effective UID is changed to portage.  Does this give anyone  
else any further ideas of what to check?


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 19:19, Jack  a
écrit :

>
> I have a suspicion that this really might be sandbox related.
> /dev/fd/whatever are all in the live system, and if I understand
> correctly, emerge works within the sandbox, so you should not be able
> to get at those files (certainly not write to them, but it isn't clear
> what the ebuild is trying to do there.)
>
> However, if you are running the emerge (please do clarify that your are
> trying to emerge bash, not just manually build it) as root, I don't see
> any reason it should try to use sudo for anything.
>
> Just for a change, try logging in as root, not doing su, and see if the
> emerge works.
>
> Jack
>

Jack,
- I don't manually build bash. Just : #emerge bash
- CTRL+Alt+F1 to get out of X and go to TTY1
- logged as root with the root password
- emerge bash stops at password required.

--
Jacques


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 19:04, Nikos Chantziaras  a
écrit :

>
> I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say
> that you should first find out what command is being executed with sudo.
> To do that, try to emerge bash, and when the sudo prompt pops up, switch
> to another terminal window and do:
>
>ps aux | grep sudo
>
> What's the output of that?
>
>
>
ps aux | grep sudo
267:root 19845  0.0  0.0  54260  4304 pts/0S+   19:23   0:00 sudo
eix-update
269:root 19857  0.0  0.0  10856   916 pts/1S+   19:24   0:00 grep
-n sudo

--
Jacques


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jack

On 2019.01.21 11:44, Jacques Montier wrote:

Le lun. 21 janv. 2019 à 15:37, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :

>
> (1). Are you attempting to build bash as yourself or as user root?
> (2). If the latter, what's in LD_PRELOAD and LD_LIBRARY_PATH?
>
> (3). What's the output of:
> ls -l /path/to/libsandbox.so?
> (4). And:
> file /path/to/libsandbox.so
>
>
(1) I always build bash as user root (su then password)
(2) there's no output with echo $LD_PRELOAD or $LD_LIBRARY_PATH
(3) libsandbox.so is located in /usr/lib32 and /usr/lib64
ls -al /usr/lib32/libsandbox.so
-rwxr-xr-x 1 root root 91720 19 janv. 19:14 /usr/lib32/libsandbox.so*
ls -al /usr/lib64/libsandbox.so
-rwxr-xr-x 1 root root 84520 19 janv. 19:14 /usr/lib64/libsandbox.so*

file /usr/lib32/libsandbox.so
/usr/lib32/libsandbox.so: ELF 32-bit LSB pie executable, Intel 80386,
version 1 (SYSV), dynamically linked, stripped
file /usr/lib64/libsandbox.so
/usr/lib64/libsandbox.so: ELF 64-bit LSB pie executable, x86-64,  
version 1

(SYSV), dynamically linked, stripped

---

BUT, i think the error is NOT libsandbox related.
As i said in a previous post, i could successfully emerge bash with a  
live

SystemRescuecd.
Here is the log (attached file) :
We could see the same error many times (>10) :

. snip
checking whether /dev/fd is available... ERROR: ld.so: object
'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open  
shared

object file): ignored.

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

sudo: no tty present and no askpass program specified

.snip

 Now the difference is : sudo: no tty present and no askpass program
specified

Does that mean that the problem comes from sudo (see the attached  
sudoers

file )?

Thanks again,

--
Jacques
I have a suspicion that this really might be sandbox related.   
/dev/fd/whatever are all in the live system, and if I understand  
correctly, emerge works within the sandbox, so you should not be able  
to get at those files (certainly not write to them, but it isn't clear  
what the ebuild is trying to do there.)


However, if you are running the emerge (please do clarify that your are  
trying to emerge bash, not just manually build it) as root, I don't see  
any reason it should try to use sudo for anything.


Just for a change, try logging in as root, not doing su, and see if the  
emerge works.


Jack


[gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Nikos Chantziaras

On 19/01/2019 12:51, Jacques Montier wrote:

I did not have any problem with bash emerge so far.
Here is the attached log.
As usual, i successfully logged with my root password (su -) and then
#emerge -uv bash

The only thing i did some days ago, was to change my user jacques password.
In the sudoers file, i have the row : jacques ALL=(ALL) NOPASSWD: ALL
So with sudo, i don't have to write the root password.

It is not version bash related as i tried to re-emerge the 
installed app-shells/bash and it fails.


I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say 
that you should first find out what command is being executed with sudo. 
To do that, try to emerge bash, and when the sudo prompt pops up, switch 
to another terminal window and do:


  ps aux | grep sudo

What's the output of that?




Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Alexander Kapshuk
On Mon, Jan 21, 2019 at 3:43 PM Jacques Montier  wrote:
>
>
> Le lun. 21 janv. 2019 à 14:16, Alexander Kapshuk 
>  a écrit :
>>
>>
>>
>> What is the output of:
>> env | grep libsandbox.so
>>
>
> There is no output of env | grep libsandbox.so, but with env | grep sandbox, 
> i get this :
>
> $ env | grep sandbox
> 13:CONFIG_PROTECT_MASK=/etc/sandbox.d /etc/php/cli-php7.2/ext-active/ 
> /etc/php/cgi-php7.2/ext-active/ /etc/php/apache2-php7.2/ext-active/ 
> /etc/fonts/fonts.conf /etc/gentoo-release /etc/gconf /etc/terminfo /etc/dconf 
> /etc/ca-certificates.conf /etc/revdep-rebuild
>
> --
> Jacques
>

(1). Are you attempting to build bash as yourself or as user root?
(2). If the latter, what's in LD_PRELOAD and LD_LIBRARY_PATH?

(3). What's the output of:
ls -l /path/to/libsandbox.so?
(4). And:
file /path/to/libsandbox.so



Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 14:16, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :

>
>
> What is the output of:
> env | grep libsandbox.so
>
>
There is no output of env | grep libsandbox.so, but with env | grep
sandbox, i get this :

$ env | grep sandbox
13:CONFIG_PROTECT_MASK=/etc/sandbox.d /etc/php/cli-php7.2/ext-active/
/etc/php/cgi-php7.2/ext-active/ /etc/php/apache2-php7.2/ext-active/
/etc/fonts/fonts.conf /etc/gentoo-release /etc/gconf /etc/terminfo
/etc/dconf /etc/ca-certificates.conf /etc/revdep-rebuild

--
Jacques


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Alexander Kapshuk
On Mon, Jan 21, 2019 at 3:03 PM Jacques Montier  wrote:
>
> Le lun. 21 janv. 2019 à 13:04, Alexander Kapshuk 
>  a écrit :
>>
>>
>>
>> What is the output of:
>> echo $LD_PRELOAD
>> echo $LD_LIBRARY_PATH
>>
>
> No output.
>
> --
> Jacques
>

So these variables are both unset. But the build log you supplied, had
a record saying the object 'libsandbox.so' could not be preloaded from
LD_PRELOAD.
Is that in your build environment, or in your regular user's
environment, or are they both the same on your system?

What is the output of:
env | grep libsandbox.so



Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 13:04, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :

>
>
> What is the output of:
> echo $LD_PRELOAD
> echo $LD_LIBRARY_PATH
>
>
No output.

--
Jacques


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Alexander Kapshuk
On Mon, Jan 21, 2019 at 1:31 PM Jacques Montier  wrote:
>
>
>
> Le lun. 21 janv. 2019 à 12:11, Alexander Kapshuk 
>  a écrit :
>
>>
>> The /proc/PID directory listed by the ls command is the directory for
>> the process that executed the ls command. See below.
>>
>> % ls -ld /proc/self &
>> [1] 27318
>> % lrwxrwxrwx 1 root root 0 Sep 24 14:06 /proc/self -> 27318
>> [1] +  Done
>>
>> As for the user/group owning the files in /proc/self, they are owned
>> by the user who initiated the process that created those entries in
>> the proc file system.
>>
>
> Thanks Alexander for your explanation.
> Nevertheless, the bash rejected password remains a mystery to me. :-(
>
> Regards,
>
>

What is the output of:
echo $LD_PRELOAD
echo $LD_LIBRARY_PATH



Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 12:11, Alexander Kapshuk <
alexander.kaps...@gmail.com> a écrit :


> The /proc/PID directory listed by the ls command is the directory for
> the process that executed the ls command. See below.
>
> % ls -ld /proc/self &
> [1] 27318
> % lrwxrwxrwx 1 root root 0 Sep 24 14:06 /proc/self -> 27318
> [1] +  Done
>
> As for the user/group owning the files in /proc/self, they are owned
> by the user who initiated the process that created those entries in
> the proc file system.
>
>
Thanks Alexander for your explanation.
Nevertheless, the bash rejected password remains a mystery to me. :-(

Regards,


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Alexander Kapshuk
On Mon, Jan 21, 2019 at 12:52 PM Jacques Montier  wrote:
>
>
> Le lun. 21 janv. 2019 à 11:21, Raffaele Belardi  a 
> écrit :
>>
>>
>> Well, they are owned by jacques instead of root. Could it be the reason why 
>> you're asked
>> for a password? Maybe some strange interaction with the sandbox?
>>
>> raffaele
>
>
>
> Yes, i noticed that, but how to explain my root password rejected when 
> emerging bash ?
>
> I also noticed something strange :
> $ ls -al /proc/self/fd
> total 0
> dr-x-- 2 jacques jacques  0 21 janv. 11:49 ./
> dr-xr-xr-x 9 jacques jacques  0 21 janv. 11:49 ../
> lrwx-- 1 jacques jacques 64 21 janv. 11:49 0 -> /dev/pts/1
> lrwx-- 1 jacques jacques 64 21 janv. 11:49 1 -> /dev/pts/1
> lrwx-- 1 jacques jacques 64 21 janv. 11:49 2 -> /dev/pts/1
> lr-x-- 1 jacques jacques 64 21 janv. 11:49 3 -> /proc/4461/fd/
>
> The /proc/4461 directory does not exist !
>
> --
> Jacques
>

The /proc/PID directory listed by the ls command is the directory for
the process that executed the ls command. See below.

% ls -ld /proc/self &
[1] 27318
% lrwxrwxrwx 1 root root 0 Sep 24 14:06 /proc/self -> 27318
[1] +  Done

As for the user/group owning the files in /proc/self, they are owned
by the user who initiated the process that created those entries in
the proc file system.



Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 11:21, Raffaele Belardi  a
écrit :

>
> Well, they are owned by jacques instead of root. Could it be the reason
> why you're asked
> for a password? Maybe some strange interaction with the sandbox?
>
> raffaele
>


Yes, i noticed that, but how to explain my root password rejected when
emerging bash ?

I also noticed something strange :
$ ls -al /proc/self/fd
total 0
dr-x-- 2 jacques jacques  0 21 janv. 11:49 ./
dr-xr-xr-x 9 jacques jacques  0 21 janv. 11:49 ../
lrwx-- 1 jacques jacques 64 21 janv. 11:49 0 -> /dev/pts/1
lrwx-- 1 jacques jacques 64 21 janv. 11:49 1 -> /dev/pts/1
lrwx-- 1 jacques jacques 64 21 janv. 11:49 2 -> /dev/pts/1
lr-x-- 1 jacques jacques 64 21 janv. 11:49 3 -> /proc/4461/fd/

The /proc/4461 directory does not exist !

--
Jacques


Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Raffaele Belardi
Jacques Montier wrote:
> /
> /
> Le lun. 21 janv. 2019 à 07:52, Raffaele Belardi  > a écrit :
> 
> Jacques Montier wrote:
> > checking whether /dev/fd is available... ERROR: ld.so: object 
> 'libsandbox.so' from
> LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
> 
> Just a guess. configure here is trying to read /dev/fd which is a symlink 
> to
> /proc/self/fd. Do you see anything strange with those two directories or 
> directory
> entries?
> 
> $ ll /dev/fd
> lrwxrwxrwx 1 root root 13 Jan 21 07:10 /dev/fd -> /proc/self/fd
> 
> 
> # ll /proc/self/fd
> total 0
> lrwx-- 1 root root 64 Jan 21 07:53 0 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 1 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 2 -> /dev/pts/3
> lr-x-- 1 root root 64 Jan 21 07:53 3 -> /proc/3744/fd
> 
> # ll /proc/self/
> total 0
> dr-x-- 2 root root 0 Jan 21 07:54 fd
> (snip)
> 
> 
> Thanks Raffaele,
> 
> No, i don't see anything strange with those two directories. Do you ?
> 
> $ ls -al /dev/fd
>  lrwxrwxrwx 1 root root 13 21 janv. 10:28 /dev/fd -> /proc/self/fd/
> 
> $ ls -al /proc/self/fd
> total 0
> dr-x-- 2 jacques jacques  0 21 janv. 10:43 ./
> dr-xr-xr-x 9 jacques jacques  0 21 janv. 10:43 ../
> lrwx-- 1 jacques jacques 64 21 janv. 10:43 0 -> /dev/pts/0
> lrwx-- 1 jacques jacques 64 21 janv. 10:43 1 -> /dev/pts/0
> lrwx-- 1 jacques jacques 64 21 janv. 10:43 2 -> /dev/pts/0
> lr-x-- 1 jacques jacques 64 21 janv. 10:43 3 -> /proc/5146/fd/
> 
> $ ls -al /proc/self/
> dr-x--   2 jacques jacques 0 21 janv. 10:44 fd/
> 

Well, they are owned by jacques instead of root. Could it be the reason why 
you're asked
for a password? Maybe some strange interaction with the sandbox?

raffaele



Re: [gentoo-user] Re: bash upgrading problem

2019-01-21 Thread Jacques Montier
Le lun. 21 janv. 2019 à 07:52, Raffaele Belardi  a
écrit :

> Jacques Montier wrote:
> > checking whether /dev/fd is available... ERROR: ld.so: object
> 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared
> object file): ignored.
>
> Just a guess. configure here is trying to read /dev/fd which is a symlink
> to
> /proc/self/fd. Do you see anything strange with those two directories or
> directory entries?
>
> $ ll /dev/fd
> lrwxrwxrwx 1 root root 13 Jan 21 07:10 /dev/fd -> /proc/self/fd
>
>
> # ll /proc/self/fd
> total 0
> lrwx-- 1 root root 64 Jan 21 07:53 0 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 1 -> /dev/pts/3
> lrwx-- 1 root root 64 Jan 21 07:53 2 -> /dev/pts/3
> lr-x-- 1 root root 64 Jan 21 07:53 3 -> /proc/3744/fd
>
> # ll /proc/self/
> total 0
> dr-x-- 2 root root 0 Jan 21 07:54 fd
> (snip)
>
>
Thanks Raffaele,

No, i don't see anything strange with those two directories. Do you ?

$ ls -al /dev/fd
 lrwxrwxrwx 1 root root 13 21 janv. 10:28 /dev/fd -> /proc/self/fd/

$ ls -al /proc/self/fd
total 0
dr-x-- 2 jacques jacques  0 21 janv. 10:43 ./
dr-xr-xr-x 9 jacques jacques  0 21 janv. 10:43 ../
lrwx-- 1 jacques jacques 64 21 janv. 10:43 0 -> /dev/pts/0
lrwx-- 1 jacques jacques 64 21 janv. 10:43 1 -> /dev/pts/0
lrwx-- 1 jacques jacques 64 21 janv. 10:43 2 -> /dev/pts/0
lr-x-- 1 jacques jacques 64 21 janv. 10:43 3 -> /proc/5146/fd/

$ ls -al /proc/self/
dr-x--   2 jacques jacques 0 21 janv. 10:44 fd/

Regards,

--
Jacques