sed not matching wildcards greedily to crop string parts
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
I have this string
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
which is the output of php -i | grep extension_dir
.
How can I parse it in bash to get the first /some/path/php/extensions/no-debug-non-zts-20160303
?
So far I have tried:
echo $(php -i | grep extension_dir | sed 's/extension_dir => //g' | sed 's/=> .*//g')
but that gives me /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. I have no idea why it doesn't replace all matches of => .*
My base idea is to get rid of first extension_dir =>
and than rid of everything after first =>
including =>
Probably sed matches things differently than regex.
linux bash sed
add a comment |Â
up vote
5
down vote
favorite
I have this string
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
which is the output of php -i | grep extension_dir
.
How can I parse it in bash to get the first /some/path/php/extensions/no-debug-non-zts-20160303
?
So far I have tried:
echo $(php -i | grep extension_dir | sed 's/extension_dir => //g' | sed 's/=> .*//g')
but that gives me /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. I have no idea why it doesn't replace all matches of => .*
My base idea is to get rid of first extension_dir =>
and than rid of everything after first =>
including =>
Probably sed matches things differently than regex.
linux bash sed
1
What is the exact output you want? It looks like it's done just what you described: all matches of=> .*
have been removed.
â JigglyNaga
Feb 16 at 12:59
There are two ouput lines instead of one and therefore sed doesn't work. I wanted to get/some/path/php/extensions/no-debug-non-zts-20160303
â simPod
Feb 16 at 13:01
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I have this string
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
which is the output of php -i | grep extension_dir
.
How can I parse it in bash to get the first /some/path/php/extensions/no-debug-non-zts-20160303
?
So far I have tried:
echo $(php -i | grep extension_dir | sed 's/extension_dir => //g' | sed 's/=> .*//g')
but that gives me /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. I have no idea why it doesn't replace all matches of => .*
My base idea is to get rid of first extension_dir =>
and than rid of everything after first =>
including =>
Probably sed matches things differently than regex.
linux bash sed
I have this string
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
which is the output of php -i | grep extension_dir
.
How can I parse it in bash to get the first /some/path/php/extensions/no-debug-non-zts-20160303
?
So far I have tried:
echo $(php -i | grep extension_dir | sed 's/extension_dir => //g' | sed 's/=> .*//g')
but that gives me /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. I have no idea why it doesn't replace all matches of => .*
My base idea is to get rid of first extension_dir =>
and than rid of everything after first =>
including =>
Probably sed matches things differently than regex.
linux bash sed
edited Feb 16 at 11:51
Kusalananda
103k13202318
103k13202318
asked Feb 16 at 11:38
simPod
1284
1284
1
What is the exact output you want? It looks like it's done just what you described: all matches of=> .*
have been removed.
â JigglyNaga
Feb 16 at 12:59
There are two ouput lines instead of one and therefore sed doesn't work. I wanted to get/some/path/php/extensions/no-debug-non-zts-20160303
â simPod
Feb 16 at 13:01
add a comment |Â
1
What is the exact output you want? It looks like it's done just what you described: all matches of=> .*
have been removed.
â JigglyNaga
Feb 16 at 12:59
There are two ouput lines instead of one and therefore sed doesn't work. I wanted to get/some/path/php/extensions/no-debug-non-zts-20160303
â simPod
Feb 16 at 13:01
1
1
What is the exact output you want? It looks like it's done just what you described: all matches of
=> .*
have been removed.â JigglyNaga
Feb 16 at 12:59
What is the exact output you want? It looks like it's done just what you described: all matches of
=> .*
have been removed.â JigglyNaga
Feb 16 at 12:59
There are two ouput lines instead of one and therefore sed doesn't work. I wanted to get
/some/path/php/extensions/no-debug-non-zts-20160303
â simPod
Feb 16 at 13:01
There are two ouput lines instead of one and therefore sed doesn't work. I wanted to get
/some/path/php/extensions/no-debug-non-zts-20160303
â simPod
Feb 16 at 13:01
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
8
down vote
accepted
php -i | sed -n '/extension_dir/s/^[^/]*//;s/ *=>.*$//;p;'
or, as suggested in comments below,
php -i | sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
The sed
above replaces your grep
and will, for every line that matches extensions_dir
, first remove everything up to the first /
and then everything from the first =>
onwards in the modified string. Any spaces before the =>
are also removed. Lines not matching extensions_dir
are ignored.
This will return the wanted path for the first line of input, and an empty line for the second.
To disregard the second line of input, use /^extension_dir/
instead of /extension_dir/
in the sed
above. This will discard the second line since does not start with that string.
It's the combination of your two sed
scripts that produces the surprising result for the second line of input.
The line is
sqlite3.extension_dir => no value => no value
and the first sed
will modify this to
sqlite3.no value => no value
The second sed
will then remove the => no value
bit at the end.
Note that
echo $( ... )
is a bit useless as it gobbles up the newlines in the output of the command inside $( ... )
. Instead test with just the command without the echo
or the $( ... )
command substitution.
It is possibly this use of echo
that has had you confused about the nature of the output from php -i
and grep
(two matching lines rather than one).
1
Shorter, and IMHO easier to read by deleting the inverted match instead of-n
and...;p
. And the anchors^
and$
seem superfluous in this case, sosed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.
â Philippos
Feb 16 at 12:04
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Kusalananda I was thinking thatsqlite3.no value
would be taken away with matching the first=>
in=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only=> /some/path/php/extensions/no-debug-non-zts-20160303
matched?
â simPod
Feb 16 at 12:29
1
@simPod Becausesed
processes its input data line by line, and you have two separate lines of input.
â Kusalananda
Feb 16 at 12:31
1
Thanks for more detailed explaination of mysed
use
â simPod
Feb 16 at 13:02
 |Â
show 2 more comments
up vote
7
down vote
I can give you a simple awk solution.
php -i | awk -F ' => ' '/extension_dir/print $2; exit'
That will work if you want to lose the sed.
EDIT: Moved exit to inside the block to avoid a syntax error, added spaces around field separator so they won't be output with the resulting filepath, and describe change in body, so stackexchange allows the edit due to minimum character change limitation.
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
add a comment |Â
up vote
2
down vote
If path doesn't contain spaces, this expression will be enough:
php -i | grep -Po 'extension_dir => K/[^ ]*'
Input
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
Output
/some/path/php/extensions/no-debug-non-zts-20160303
add a comment |Â
up vote
-1
down vote
echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')
1
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
php -i | sed -n '/extension_dir/s/^[^/]*//;s/ *=>.*$//;p;'
or, as suggested in comments below,
php -i | sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
The sed
above replaces your grep
and will, for every line that matches extensions_dir
, first remove everything up to the first /
and then everything from the first =>
onwards in the modified string. Any spaces before the =>
are also removed. Lines not matching extensions_dir
are ignored.
This will return the wanted path for the first line of input, and an empty line for the second.
To disregard the second line of input, use /^extension_dir/
instead of /extension_dir/
in the sed
above. This will discard the second line since does not start with that string.
It's the combination of your two sed
scripts that produces the surprising result for the second line of input.
The line is
sqlite3.extension_dir => no value => no value
and the first sed
will modify this to
sqlite3.no value => no value
The second sed
will then remove the => no value
bit at the end.
Note that
echo $( ... )
is a bit useless as it gobbles up the newlines in the output of the command inside $( ... )
. Instead test with just the command without the echo
or the $( ... )
command substitution.
It is possibly this use of echo
that has had you confused about the nature of the output from php -i
and grep
(two matching lines rather than one).
1
Shorter, and IMHO easier to read by deleting the inverted match instead of-n
and...;p
. And the anchors^
and$
seem superfluous in this case, sosed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.
â Philippos
Feb 16 at 12:04
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Kusalananda I was thinking thatsqlite3.no value
would be taken away with matching the first=>
in=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only=> /some/path/php/extensions/no-debug-non-zts-20160303
matched?
â simPod
Feb 16 at 12:29
1
@simPod Becausesed
processes its input data line by line, and you have two separate lines of input.
â Kusalananda
Feb 16 at 12:31
1
Thanks for more detailed explaination of mysed
use
â simPod
Feb 16 at 13:02
 |Â
show 2 more comments
up vote
8
down vote
accepted
php -i | sed -n '/extension_dir/s/^[^/]*//;s/ *=>.*$//;p;'
or, as suggested in comments below,
php -i | sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
The sed
above replaces your grep
and will, for every line that matches extensions_dir
, first remove everything up to the first /
and then everything from the first =>
onwards in the modified string. Any spaces before the =>
are also removed. Lines not matching extensions_dir
are ignored.
This will return the wanted path for the first line of input, and an empty line for the second.
To disregard the second line of input, use /^extension_dir/
instead of /extension_dir/
in the sed
above. This will discard the second line since does not start with that string.
It's the combination of your two sed
scripts that produces the surprising result for the second line of input.
The line is
sqlite3.extension_dir => no value => no value
and the first sed
will modify this to
sqlite3.no value => no value
The second sed
will then remove the => no value
bit at the end.
Note that
echo $( ... )
is a bit useless as it gobbles up the newlines in the output of the command inside $( ... )
. Instead test with just the command without the echo
or the $( ... )
command substitution.
It is possibly this use of echo
that has had you confused about the nature of the output from php -i
and grep
(two matching lines rather than one).
1
Shorter, and IMHO easier to read by deleting the inverted match instead of-n
and...;p
. And the anchors^
and$
seem superfluous in this case, sosed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.
â Philippos
Feb 16 at 12:04
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Kusalananda I was thinking thatsqlite3.no value
would be taken away with matching the first=>
in=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only=> /some/path/php/extensions/no-debug-non-zts-20160303
matched?
â simPod
Feb 16 at 12:29
1
@simPod Becausesed
processes its input data line by line, and you have two separate lines of input.
â Kusalananda
Feb 16 at 12:31
1
Thanks for more detailed explaination of mysed
use
â simPod
Feb 16 at 13:02
 |Â
show 2 more comments
up vote
8
down vote
accepted
up vote
8
down vote
accepted
php -i | sed -n '/extension_dir/s/^[^/]*//;s/ *=>.*$//;p;'
or, as suggested in comments below,
php -i | sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
The sed
above replaces your grep
and will, for every line that matches extensions_dir
, first remove everything up to the first /
and then everything from the first =>
onwards in the modified string. Any spaces before the =>
are also removed. Lines not matching extensions_dir
are ignored.
This will return the wanted path for the first line of input, and an empty line for the second.
To disregard the second line of input, use /^extension_dir/
instead of /extension_dir/
in the sed
above. This will discard the second line since does not start with that string.
It's the combination of your two sed
scripts that produces the surprising result for the second line of input.
The line is
sqlite3.extension_dir => no value => no value
and the first sed
will modify this to
sqlite3.no value => no value
The second sed
will then remove the => no value
bit at the end.
Note that
echo $( ... )
is a bit useless as it gobbles up the newlines in the output of the command inside $( ... )
. Instead test with just the command without the echo
or the $( ... )
command substitution.
It is possibly this use of echo
that has had you confused about the nature of the output from php -i
and grep
(two matching lines rather than one).
php -i | sed -n '/extension_dir/s/^[^/]*//;s/ *=>.*$//;p;'
or, as suggested in comments below,
php -i | sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
The sed
above replaces your grep
and will, for every line that matches extensions_dir
, first remove everything up to the first /
and then everything from the first =>
onwards in the modified string. Any spaces before the =>
are also removed. Lines not matching extensions_dir
are ignored.
This will return the wanted path for the first line of input, and an empty line for the second.
To disregard the second line of input, use /^extension_dir/
instead of /extension_dir/
in the sed
above. This will discard the second line since does not start with that string.
It's the combination of your two sed
scripts that produces the surprising result for the second line of input.
The line is
sqlite3.extension_dir => no value => no value
and the first sed
will modify this to
sqlite3.no value => no value
The second sed
will then remove the => no value
bit at the end.
Note that
echo $( ... )
is a bit useless as it gobbles up the newlines in the output of the command inside $( ... )
. Instead test with just the command without the echo
or the $( ... )
command substitution.
It is possibly this use of echo
that has had you confused about the nature of the output from php -i
and grep
(two matching lines rather than one).
edited Feb 16 at 19:04
answered Feb 16 at 11:46
Kusalananda
103k13202318
103k13202318
1
Shorter, and IMHO easier to read by deleting the inverted match instead of-n
and...;p
. And the anchors^
and$
seem superfluous in this case, sosed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.
â Philippos
Feb 16 at 12:04
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Kusalananda I was thinking thatsqlite3.no value
would be taken away with matching the first=>
in=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only=> /some/path/php/extensions/no-debug-non-zts-20160303
matched?
â simPod
Feb 16 at 12:29
1
@simPod Becausesed
processes its input data line by line, and you have two separate lines of input.
â Kusalananda
Feb 16 at 12:31
1
Thanks for more detailed explaination of mysed
use
â simPod
Feb 16 at 13:02
 |Â
show 2 more comments
1
Shorter, and IMHO easier to read by deleting the inverted match instead of-n
and...;p
. And the anchors^
and$
seem superfluous in this case, sosed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.
â Philippos
Feb 16 at 12:04
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Kusalananda I was thinking thatsqlite3.no value
would be taken away with matching the first=>
in=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched=> /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only=> /some/path/php/extensions/no-debug-non-zts-20160303
matched?
â simPod
Feb 16 at 12:29
1
@simPod Becausesed
processes its input data line by line, and you have two separate lines of input.
â Kusalananda
Feb 16 at 12:31
1
Thanks for more detailed explaination of mysed
use
â simPod
Feb 16 at 13:02
1
1
Shorter, and IMHO easier to read by deleting the inverted match instead of
-n
and ...;p
. And the anchors ^
and $
seem superfluous in this case, so sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.â Philippos
Feb 16 at 12:04
Shorter, and IMHO easier to read by deleting the inverted match instead of
-n
and ...;p
. And the anchors ^
and $
seem superfluous in this case, so sed '/extension_dir/!d;s/[^/]*//;s/ *=>.*//'
would do the same job.â Philippos
Feb 16 at 12:04
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Philippos Yes. Thanks. I've added this.
â Kusalananda
Feb 16 at 12:07
@Kusalananda I was thinking that
sqlite3.no value
would be taken away with matching the first =>
in => /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched => /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only => /some/path/php/extensions/no-debug-non-zts-20160303
matched?â simPod
Feb 16 at 12:29
@Kusalananda I was thinking that
sqlite3.no value
would be taken away with matching the first =>
in => /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value => no value
. So this would have been matched => /some/path/php/extensions/no-debug-non-zts-20160303 sqlite3.no value
. Why was only => /some/path/php/extensions/no-debug-non-zts-20160303
matched?â simPod
Feb 16 at 12:29
1
1
@simPod Because
sed
processes its input data line by line, and you have two separate lines of input.â Kusalananda
Feb 16 at 12:31
@simPod Because
sed
processes its input data line by line, and you have two separate lines of input.â Kusalananda
Feb 16 at 12:31
1
1
Thanks for more detailed explaination of my
sed
useâ simPod
Feb 16 at 13:02
Thanks for more detailed explaination of my
sed
useâ simPod
Feb 16 at 13:02
 |Â
show 2 more comments
up vote
7
down vote
I can give you a simple awk solution.
php -i | awk -F ' => ' '/extension_dir/print $2; exit'
That will work if you want to lose the sed.
EDIT: Moved exit to inside the block to avoid a syntax error, added spaces around field separator so they won't be output with the resulting filepath, and describe change in body, so stackexchange allows the edit due to minimum character change limitation.
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
add a comment |Â
up vote
7
down vote
I can give you a simple awk solution.
php -i | awk -F ' => ' '/extension_dir/print $2; exit'
That will work if you want to lose the sed.
EDIT: Moved exit to inside the block to avoid a syntax error, added spaces around field separator so they won't be output with the resulting filepath, and describe change in body, so stackexchange allows the edit due to minimum character change limitation.
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
add a comment |Â
up vote
7
down vote
up vote
7
down vote
I can give you a simple awk solution.
php -i | awk -F ' => ' '/extension_dir/print $2; exit'
That will work if you want to lose the sed.
EDIT: Moved exit to inside the block to avoid a syntax error, added spaces around field separator so they won't be output with the resulting filepath, and describe change in body, so stackexchange allows the edit due to minimum character change limitation.
I can give you a simple awk solution.
php -i | awk -F ' => ' '/extension_dir/print $2; exit'
That will work if you want to lose the sed.
EDIT: Moved exit to inside the block to avoid a syntax error, added spaces around field separator so they won't be output with the resulting filepath, and describe change in body, so stackexchange allows the edit due to minimum character change limitation.
edited Feb 17 at 0:46
JoL
68819
68819
answered Feb 16 at 11:46
alpha
1,241317
1,241317
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
add a comment |Â
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Very simple, thanks! I might probably use this one. However, marked Kusalananda's aswer as accepted as it explains the sed problem and that was the original question.
â simPod
Feb 16 at 13:05
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
Yes, awk is a much better choice for columnar data such as this - exactly the answer I thought of when I read the question.
â Toby Speight
Feb 16 at 14:58
add a comment |Â
up vote
2
down vote
If path doesn't contain spaces, this expression will be enough:
php -i | grep -Po 'extension_dir => K/[^ ]*'
Input
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
Output
/some/path/php/extensions/no-debug-non-zts-20160303
add a comment |Â
up vote
2
down vote
If path doesn't contain spaces, this expression will be enough:
php -i | grep -Po 'extension_dir => K/[^ ]*'
Input
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
Output
/some/path/php/extensions/no-debug-non-zts-20160303
add a comment |Â
up vote
2
down vote
up vote
2
down vote
If path doesn't contain spaces, this expression will be enough:
php -i | grep -Po 'extension_dir => K/[^ ]*'
Input
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
Output
/some/path/php/extensions/no-debug-non-zts-20160303
If path doesn't contain spaces, this expression will be enough:
php -i | grep -Po 'extension_dir => K/[^ ]*'
Input
extension_dir => /some/path/php/extensions/no-debug-non-zts-20160303 => /some/path/php/extensions/no-debug-non-zts-20160303
sqlite3.extension_dir => no value => no value
Output
/some/path/php/extensions/no-debug-non-zts-20160303
answered Feb 16 at 12:13
MiniMax
2,681718
2,681718
add a comment |Â
add a comment |Â
up vote
-1
down vote
echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')
1
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
add a comment |Â
up vote
-1
down vote
echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')
1
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')
echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')
answered Feb 17 at 12:37
Budi
112
112
1
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
add a comment |Â
1
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
1
1
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
I believe that the point may be that the path is unknown.
â Kusalananda
Feb 17 at 13:24
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f424583%2fsed-not-matching-wildcards-greedily-to-crop-string-parts%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
What is the exact output you want? It looks like it's done just what you described: all matches of
=> .*
have been removed.â JigglyNaga
Feb 16 at 12:59
There are two ouput lines instead of one and therefore sed doesn't work. I wanted to get
/some/path/php/extensions/no-debug-non-zts-20160303
â simPod
Feb 16 at 13:01