sed not matching wildcards greedily to crop string parts

The name of the pictureThe name of the pictureThe name of the pictureClash 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.







share|improve this question


















  • 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














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.







share|improve this question


















  • 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












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.







share|improve this question














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.









share|improve this question













share|improve this question




share|improve this question








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












  • 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










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).






share|improve this answer


















  • 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










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







  • 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






  • 1




    Thanks for more detailed explaination of my sed use
    – simPod
    Feb 16 at 13:02

















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.






share|improve this answer






















  • 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

















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





share|improve this answer



























    up vote
    -1
    down vote













    echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')





    share|improve this answer
















    • 1




      I believe that the point may be that the path is unknown.
      – Kusalananda
      Feb 17 at 13:24










    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    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






























    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).






    share|improve this answer


















    • 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










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







    • 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






    • 1




      Thanks for more detailed explaination of my sed use
      – simPod
      Feb 16 at 13:02














    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).






    share|improve this answer


















    • 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










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







    • 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






    • 1




      Thanks for more detailed explaination of my sed use
      – simPod
      Feb 16 at 13:02












    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).






    share|improve this answer














    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).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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, 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










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




      @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




      Thanks for more detailed explaination of my sed use
      – simPod
      Feb 16 at 13:02












    • 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










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







    • 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






    • 1




      Thanks for more detailed explaination of my sed 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












    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.






    share|improve this answer






















    • 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














    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.






    share|improve this answer






















    • 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












    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.






    share|improve this answer














    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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
















    • 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










    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





    share|improve this answer
























      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





      share|improve this answer






















        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





        share|improve this answer












        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






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 16 at 12:13









        MiniMax

        2,681718




        2,681718




















            up vote
            -1
            down vote













            echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')





            share|improve this answer
















            • 1




              I believe that the point may be that the path is unknown.
              – Kusalananda
              Feb 17 at 13:24














            up vote
            -1
            down vote













            echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')





            share|improve this answer
















            • 1




              I believe that the point may be that the path is unknown.
              – Kusalananda
              Feb 17 at 13:24












            up vote
            -1
            down vote










            up vote
            -1
            down vote









            echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')





            share|improve this answer












            echo $(php -i | grep -Poie '/some/path/php/extensions/no-debug-non-zts-20160303')






            share|improve this answer












            share|improve this answer



            share|improve this answer










            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












            • 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












             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?