NUL delimited variableHow to name a file in the deepest level of a directory treeUsing a variable inside a sequence of commands in bash to supplement an existing string - syntax error or flawed design?How to use bash's complete or compgen -C (command) option?how to get the standard output from command in variableSaving command output to a variable in bash results in “Unescaped left brace in regex is deprecated”Confusion about bash command vs. variable substitutionHow to iterate a command with two different variables?tail/head piping remove newlinesPotential workaround to inotifywait can't produce NUL-delimited outputHow can I prevent command substitution from removing NUL and trailing newline(s)?

What plausible reason could I give for my FTL drive only working in space

Who is "He that flies" in Lord of the Rings?

A Salute to Poetry

Extracting data from Plot

Why is the length of the Kelvin unit of temperature equal to that of the Celsius unit?

Grep Match and extract

How to destroy a galactic level civilization and still leave behind primitive survivors?

Trying to get (more) accurate readings from thermistor (electronics, math, and code inside)

Remove border lines of SRTM tiles rendered as hillshade

Could a person damage a jet airliner - from the outside - with their bare hands?

Should I put programming books I wrote a few years ago on my resume?

Does the new finding on "reversing a quantum jump mid-flight" rule out any interpretations of QM?

As easy as Three, Two, One... How fast can you go from Five to Four?

How durable are silver inlays on a blade?

So a part of my house disappeared... But not because of a chunk resetting

The origin of the Russian proverb about two hares

Why did the World Bank set the global poverty line at $1.90?

What should I discuss with my DM prior to my first game?

Does a (nice) centerless group always have a centerless profinite completion?

How do we say "within a kilometer radius spherically"?

Zig-zag function - coded solution

How and why do references in academic papers work?

Analogy between an unknown in an argument, and a contradiction in the principle of explosion

Suppose leased car is totalled: what are financial implications?



NUL delimited variable


How to name a file in the deepest level of a directory treeUsing a variable inside a sequence of commands in bash to supplement an existing string - syntax error or flawed design?How to use bash's complete or compgen -C (command) option?how to get the standard output from command in variableSaving command output to a variable in bash results in “Unescaped left brace in regex is deprecated”Confusion about bash command vs. variable substitutionHow to iterate a command with two different variables?tail/head piping remove newlinesPotential workaround to inotifywait can't produce NUL-delimited outputHow can I prevent command substitution from removing NUL and trailing newline(s)?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








2















GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)



Idea is to set a variable to a NUL delimited data set. Here $samples



This, however, result in:




warning: command substitution: ignored null byte in input




when doing:



samples="$(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)"


Thought I could re-use this variable as I need to iterate the same values multiple times:



while IFS= read -rd '' sample; do
echo $sample
done<<< "$samples"


I could use n over in the find command in this exact case, but would like to know how, if possible, to do it with NUL delimiter generally speaking.



Optionally I could do:



while IFS= read -rd '' sample; do
echo $sample
done< <(find . -type d -iregex './E[0-9][0-9]' -printf "%f" | sort -z)


but - as I need to loop it several times it makes for some very redundant code - and would have to run the find and sort command each time.



Convert the result into an array perhaps?




  • Is this possible?

  • Why can not NUL delimited data be used as is?









share|improve this question



















  • 1





    See also Why is looping over find's output bad practice? where several approaches are given to loop over find's output reliably.

    – Stéphane Chazelas
    7 hours ago











  • Why are you sorting the filenames? They would be sorted lexicographically anyway.

    – Kusalananda
    6 hours ago











  • @Kusalananda: Not in result from find. The inode table (or Directory Entries is perhaps more correct) is not sorted. No idea how find is implemented, but if it uses readdir, it is unlikely the names will be sorted in any fashion, man7.org/linux/man-pages/man3/readdir.3.html#NOTES and ext4.wiki.kernel.org/index.php/… so perhaps in some hash order. en.wikipedia.org/wiki/HTree

    – user3342816
    6 hours ago












  • @user3342816 Ah, yes. Your are absolutely correct. Sorry for the noise.

    – Kusalananda
    6 hours ago

















2















GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)



Idea is to set a variable to a NUL delimited data set. Here $samples



This, however, result in:




warning: command substitution: ignored null byte in input




when doing:



samples="$(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)"


Thought I could re-use this variable as I need to iterate the same values multiple times:



while IFS= read -rd '' sample; do
echo $sample
done<<< "$samples"


I could use n over in the find command in this exact case, but would like to know how, if possible, to do it with NUL delimiter generally speaking.



Optionally I could do:



while IFS= read -rd '' sample; do
echo $sample
done< <(find . -type d -iregex './E[0-9][0-9]' -printf "%f" | sort -z)


but - as I need to loop it several times it makes for some very redundant code - and would have to run the find and sort command each time.



Convert the result into an array perhaps?




  • Is this possible?

  • Why can not NUL delimited data be used as is?









share|improve this question



















  • 1





    See also Why is looping over find's output bad practice? where several approaches are given to loop over find's output reliably.

    – Stéphane Chazelas
    7 hours ago











  • Why are you sorting the filenames? They would be sorted lexicographically anyway.

    – Kusalananda
    6 hours ago











  • @Kusalananda: Not in result from find. The inode table (or Directory Entries is perhaps more correct) is not sorted. No idea how find is implemented, but if it uses readdir, it is unlikely the names will be sorted in any fashion, man7.org/linux/man-pages/man3/readdir.3.html#NOTES and ext4.wiki.kernel.org/index.php/… so perhaps in some hash order. en.wikipedia.org/wiki/HTree

    – user3342816
    6 hours ago












  • @user3342816 Ah, yes. Your are absolutely correct. Sorry for the noise.

    – Kusalananda
    6 hours ago













2












2








2


1






GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)



Idea is to set a variable to a NUL delimited data set. Here $samples



This, however, result in:




warning: command substitution: ignored null byte in input




when doing:



samples="$(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)"


Thought I could re-use this variable as I need to iterate the same values multiple times:



while IFS= read -rd '' sample; do
echo $sample
done<<< "$samples"


I could use n over in the find command in this exact case, but would like to know how, if possible, to do it with NUL delimiter generally speaking.



Optionally I could do:



while IFS= read -rd '' sample; do
echo $sample
done< <(find . -type d -iregex './E[0-9][0-9]' -printf "%f" | sort -z)


but - as I need to loop it several times it makes for some very redundant code - and would have to run the find and sort command each time.



Convert the result into an array perhaps?




  • Is this possible?

  • Why can not NUL delimited data be used as is?









share|improve this question
















GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)



Idea is to set a variable to a NUL delimited data set. Here $samples



This, however, result in:




warning: command substitution: ignored null byte in input




when doing:



samples="$(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)"


Thought I could re-use this variable as I need to iterate the same values multiple times:



while IFS= read -rd '' sample; do
echo $sample
done<<< "$samples"


I could use n over in the find command in this exact case, but would like to know how, if possible, to do it with NUL delimiter generally speaking.



Optionally I could do:



while IFS= read -rd '' sample; do
echo $sample
done< <(find . -type d -iregex './E[0-9][0-9]' -printf "%f" | sort -z)


but - as I need to loop it several times it makes for some very redundant code - and would have to run the find and sort command each time.



Convert the result into an array perhaps?




  • Is this possible?

  • Why can not NUL delimited data be used as is?






bash command-substitution






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 8 hours ago









ilkkachu

64.3k10107186




64.3k10107186










asked 9 hours ago









user3342816user3342816

616




616







  • 1





    See also Why is looping over find's output bad practice? where several approaches are given to loop over find's output reliably.

    – Stéphane Chazelas
    7 hours ago











  • Why are you sorting the filenames? They would be sorted lexicographically anyway.

    – Kusalananda
    6 hours ago











  • @Kusalananda: Not in result from find. The inode table (or Directory Entries is perhaps more correct) is not sorted. No idea how find is implemented, but if it uses readdir, it is unlikely the names will be sorted in any fashion, man7.org/linux/man-pages/man3/readdir.3.html#NOTES and ext4.wiki.kernel.org/index.php/… so perhaps in some hash order. en.wikipedia.org/wiki/HTree

    – user3342816
    6 hours ago












  • @user3342816 Ah, yes. Your are absolutely correct. Sorry for the noise.

    – Kusalananda
    6 hours ago












  • 1





    See also Why is looping over find's output bad practice? where several approaches are given to loop over find's output reliably.

    – Stéphane Chazelas
    7 hours ago











  • Why are you sorting the filenames? They would be sorted lexicographically anyway.

    – Kusalananda
    6 hours ago











  • @Kusalananda: Not in result from find. The inode table (or Directory Entries is perhaps more correct) is not sorted. No idea how find is implemented, but if it uses readdir, it is unlikely the names will be sorted in any fashion, man7.org/linux/man-pages/man3/readdir.3.html#NOTES and ext4.wiki.kernel.org/index.php/… so perhaps in some hash order. en.wikipedia.org/wiki/HTree

    – user3342816
    6 hours ago












  • @user3342816 Ah, yes. Your are absolutely correct. Sorry for the noise.

    – Kusalananda
    6 hours ago







1




1





See also Why is looping over find's output bad practice? where several approaches are given to loop over find's output reliably.

– Stéphane Chazelas
7 hours ago





See also Why is looping over find's output bad practice? where several approaches are given to loop over find's output reliably.

– Stéphane Chazelas
7 hours ago













Why are you sorting the filenames? They would be sorted lexicographically anyway.

– Kusalananda
6 hours ago





Why are you sorting the filenames? They would be sorted lexicographically anyway.

– Kusalananda
6 hours ago













@Kusalananda: Not in result from find. The inode table (or Directory Entries is perhaps more correct) is not sorted. No idea how find is implemented, but if it uses readdir, it is unlikely the names will be sorted in any fashion, man7.org/linux/man-pages/man3/readdir.3.html#NOTES and ext4.wiki.kernel.org/index.php/… so perhaps in some hash order. en.wikipedia.org/wiki/HTree

– user3342816
6 hours ago






@Kusalananda: Not in result from find. The inode table (or Directory Entries is perhaps more correct) is not sorted. No idea how find is implemented, but if it uses readdir, it is unlikely the names will be sorted in any fashion, man7.org/linux/man-pages/man3/readdir.3.html#NOTES and ext4.wiki.kernel.org/index.php/… so perhaps in some hash order. en.wikipedia.org/wiki/HTree

– user3342816
6 hours ago














@user3342816 Ah, yes. Your are absolutely correct. Sorry for the noise.

– Kusalananda
6 hours ago





@user3342816 Ah, yes. Your are absolutely correct. Sorry for the noise.

– Kusalananda
6 hours ago










2 Answers
2






active

oldest

votes


















4














It is a fact that you can't store null bytes in a bash string context, because of the underlying C implementation. See Why $'' or $'x0' is an empty string? Should be the null-character, isn't it?.



One option would be strip off the null bytes after the sort command, at the end of the pipeline using tr and store the result to solve the immediate problem of the warning message thrown. But that would still leave your logic flawed as the filenames with newlines would still be broken.



Use an array, use the mapfile or readarray command (on bash 4.4+) to directly slurp in the results from the find command



IFS= readarray -t -d '' samples < <(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)





share|improve this answer

























  • Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

    – user3342816
    8 hours ago











  • @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

    – Inian
    8 hours ago












  • From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

    – user3342816
    8 hours ago











  • Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

    – user3342816
    8 hours ago











  • @user3342816 : Then I suppose the readarray option is the one you want

    – Inian
    8 hours ago


















4














The bash shell does not support what you want to do. The zsh shell does out of the box.



% mkdir sample11 SAMple12 sample21 sample22 dir1
% ll
total 20
drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 dir1
drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample11
drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 SAMple12
drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample21
drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample22
% samples=$(find . -type d -iregex './sample[0-9][0-9]' -print0 | sort -z)
% echo $samples
./sample11./SAMple12./sample21./sample22
% echo $samples | od -a
0000000 . / s a m p l e 1 1 nul . / S A M
0000020 p l e 1 2 nul . / s a m p l e 2 1
0000040 nul . / s a m p l e 2 2 nul nl
0000055
%





share|improve this answer

























    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',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    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%2f523855%2fnul-delimited-variable%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    4














    It is a fact that you can't store null bytes in a bash string context, because of the underlying C implementation. See Why $'' or $'x0' is an empty string? Should be the null-character, isn't it?.



    One option would be strip off the null bytes after the sort command, at the end of the pipeline using tr and store the result to solve the immediate problem of the warning message thrown. But that would still leave your logic flawed as the filenames with newlines would still be broken.



    Use an array, use the mapfile or readarray command (on bash 4.4+) to directly slurp in the results from the find command



    IFS= readarray -t -d '' samples < <(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)





    share|improve this answer

























    • Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

      – user3342816
      8 hours ago











    • @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

      – Inian
      8 hours ago












    • From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

      – user3342816
      8 hours ago











    • Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

      – user3342816
      8 hours ago











    • @user3342816 : Then I suppose the readarray option is the one you want

      – Inian
      8 hours ago















    4














    It is a fact that you can't store null bytes in a bash string context, because of the underlying C implementation. See Why $'' or $'x0' is an empty string? Should be the null-character, isn't it?.



    One option would be strip off the null bytes after the sort command, at the end of the pipeline using tr and store the result to solve the immediate problem of the warning message thrown. But that would still leave your logic flawed as the filenames with newlines would still be broken.



    Use an array, use the mapfile or readarray command (on bash 4.4+) to directly slurp in the results from the find command



    IFS= readarray -t -d '' samples < <(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)





    share|improve this answer

























    • Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

      – user3342816
      8 hours ago











    • @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

      – Inian
      8 hours ago












    • From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

      – user3342816
      8 hours ago











    • Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

      – user3342816
      8 hours ago











    • @user3342816 : Then I suppose the readarray option is the one you want

      – Inian
      8 hours ago













    4












    4








    4







    It is a fact that you can't store null bytes in a bash string context, because of the underlying C implementation. See Why $'' or $'x0' is an empty string? Should be the null-character, isn't it?.



    One option would be strip off the null bytes after the sort command, at the end of the pipeline using tr and store the result to solve the immediate problem of the warning message thrown. But that would still leave your logic flawed as the filenames with newlines would still be broken.



    Use an array, use the mapfile or readarray command (on bash 4.4+) to directly slurp in the results from the find command



    IFS= readarray -t -d '' samples < <(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)





    share|improve this answer















    It is a fact that you can't store null bytes in a bash string context, because of the underlying C implementation. See Why $'' or $'x0' is an empty string? Should be the null-character, isn't it?.



    One option would be strip off the null bytes after the sort command, at the end of the pipeline using tr and store the result to solve the immediate problem of the warning message thrown. But that would still leave your logic flawed as the filenames with newlines would still be broken.



    Use an array, use the mapfile or readarray command (on bash 4.4+) to directly slurp in the results from the find command



    IFS= readarray -t -d '' samples < <(find . -type d -iregex './sample[0-9][0-9]' -printf "%f" | sort -z)






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 8 hours ago

























    answered 9 hours ago









    InianInian

    6,4201734




    6,4201734












    • Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

      – user3342816
      8 hours ago











    • @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

      – Inian
      8 hours ago












    • From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

      – user3342816
      8 hours ago











    • Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

      – user3342816
      8 hours ago











    • @user3342816 : Then I suppose the readarray option is the one you want

      – Inian
      8 hours ago

















    • Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

      – user3342816
      8 hours ago











    • @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

      – Inian
      8 hours ago












    • From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

      – user3342816
      8 hours ago











    • Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

      – user3342816
      8 hours ago











    • @user3342816 : Then I suppose the readarray option is the one you want

      – Inian
      8 hours ago
















    Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

    – user3342816
    8 hours ago





    Thank you. But would it not then be the same as using -printf "%fn"? If one are separating with newline in the result one are assuming there are no newlines in the data anyway (if you get what I mean). The whole point of using zero delimiter is to be sure one do not split names with newlines in them …

    – user3342816
    8 hours ago













    @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

    – Inian
    8 hours ago






    @user3342816: I thought your intention was to run the find command once, so after sorting the results, you wouldn't need the null delimited output anymore, so store the result in the variable without it

    – Inian
    8 hours ago














    From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

    – user3342816
    8 hours ago





    From the link you posted (tried to find something like that first) I read it as it is not possible to store zero in a var, so that much set array to be the "only" option.

    – user3342816
    8 hours ago













    Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

    – user3342816
    8 hours ago





    Yes. That was the intention. But if a value can have new-line, the result would be ambiguous even if sorted correctly.

    – user3342816
    8 hours ago













    @user3342816 : Then I suppose the readarray option is the one you want

    – Inian
    8 hours ago





    @user3342816 : Then I suppose the readarray option is the one you want

    – Inian
    8 hours ago













    4














    The bash shell does not support what you want to do. The zsh shell does out of the box.



    % mkdir sample11 SAMple12 sample21 sample22 dir1
    % ll
    total 20
    drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 dir1
    drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample11
    drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 SAMple12
    drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample21
    drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample22
    % samples=$(find . -type d -iregex './sample[0-9][0-9]' -print0 | sort -z)
    % echo $samples
    ./sample11./SAMple12./sample21./sample22
    % echo $samples | od -a
    0000000 . / s a m p l e 1 1 nul . / S A M
    0000020 p l e 1 2 nul . / s a m p l e 2 1
    0000040 nul . / s a m p l e 2 2 nul nl
    0000055
    %





    share|improve this answer





























      4














      The bash shell does not support what you want to do. The zsh shell does out of the box.



      % mkdir sample11 SAMple12 sample21 sample22 dir1
      % ll
      total 20
      drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 dir1
      drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample11
      drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 SAMple12
      drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample21
      drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample22
      % samples=$(find . -type d -iregex './sample[0-9][0-9]' -print0 | sort -z)
      % echo $samples
      ./sample11./SAMple12./sample21./sample22
      % echo $samples | od -a
      0000000 . / s a m p l e 1 1 nul . / S A M
      0000020 p l e 1 2 nul . / s a m p l e 2 1
      0000040 nul . / s a m p l e 2 2 nul nl
      0000055
      %





      share|improve this answer



























        4












        4








        4







        The bash shell does not support what you want to do. The zsh shell does out of the box.



        % mkdir sample11 SAMple12 sample21 sample22 dir1
        % ll
        total 20
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 dir1
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample11
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 SAMple12
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample21
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample22
        % samples=$(find . -type d -iregex './sample[0-9][0-9]' -print0 | sort -z)
        % echo $samples
        ./sample11./SAMple12./sample21./sample22
        % echo $samples | od -a
        0000000 . / s a m p l e 1 1 nul . / S A M
        0000020 p l e 1 2 nul . / s a m p l e 2 1
        0000040 nul . / s a m p l e 2 2 nul nl
        0000055
        %





        share|improve this answer















        The bash shell does not support what you want to do. The zsh shell does out of the box.



        % mkdir sample11 SAMple12 sample21 sample22 dir1
        % ll
        total 20
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 dir1
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample11
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 SAMple12
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample21
        drwxrwxr-x 2 fpm fpm 4096 Jun 9 13:46 sample22
        % samples=$(find . -type d -iregex './sample[0-9][0-9]' -print0 | sort -z)
        % echo $samples
        ./sample11./SAMple12./sample21./sample22
        % echo $samples | od -a
        0000000 . / s a m p l e 1 1 nul . / S A M
        0000020 p l e 1 2 nul . / s a m p l e 2 1
        0000040 nul . / s a m p l e 2 2 nul nl
        0000055
        %






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 4 hours ago









        terdon

        136k33276457




        136k33276457










        answered 6 hours ago









        fpmurphyfpmurphy

        2,5001016




        2,5001016



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f523855%2fnul-delimited-variable%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

            Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

            Ласкавець круглолистий Зміст Опис | Поширення | Галерея | Примітки | Посилання | Навігаційне меню58171138361-22960890446Bupleurum rotundifoliumEuro+Med PlantbasePlants of the World Online — Kew ScienceGermplasm Resources Information Network (GRIN)Ласкавецькн. VI : Літери Ком — Левиправивши або дописавши її