Bash throws error, line 8: $1: unbound variable












2















I am trying to learn how to use getopts so that I can have scripts with parsed input (although I think getopts could be better). I am trying to just write a simple script to return partition usage percentages. The problem is that one of my bash functions does not seem to like that I reference $1 as an variable within the function. The reason I reference $1 is because the get_percent function can be passed a mount point as an optional argument to display instead of all of the mount points.



The script



#!/usr/bin/bash

set -e
set -u
set -o pipefail

get_percent(){
if [ -n "$1" ]
then
df -h $1 | tail -n +2 | awk '{ print $1,"t",$5 }'
else
df -h | tail -n +2 | awk '{ print $1,"t",$5 }'
fi
}

usage(){
echo "script usage: $(basename $0) [-h] [-p] [-m mount_point]" >&2
}

# If the user doesn't supply any arguments, we run the script as normal
if [ $# -eq 0 ];
then
get_percent
exit 0
fi
# ...


The Output



$ bash thing.sh
thing.sh: line 8: $1: unbound variable

$ bash -x thing.sh
+ set -e
+ set -u
+ set -o pipefail
+ '[' 0 -eq 0 ']'
+ get_percent
thing.sh: line 8: $1: unbound variable









share|improve this question

























  • I don't think this has anything to do with getopts, does it? Your script exits due to -u before calling getopts.

    – ilkkachu
    Aug 16 '18 at 18:31











  • @ikkachu no I guess it doesn't. But I'm not sure I can change the title now.

    – Timothy Pulliam
    Aug 16 '18 at 18:33











  • There should be that small "edit" text under the post, just beneath the tags in a question

    – ilkkachu
    Aug 16 '18 at 18:36
















2















I am trying to learn how to use getopts so that I can have scripts with parsed input (although I think getopts could be better). I am trying to just write a simple script to return partition usage percentages. The problem is that one of my bash functions does not seem to like that I reference $1 as an variable within the function. The reason I reference $1 is because the get_percent function can be passed a mount point as an optional argument to display instead of all of the mount points.



The script



#!/usr/bin/bash

set -e
set -u
set -o pipefail

get_percent(){
if [ -n "$1" ]
then
df -h $1 | tail -n +2 | awk '{ print $1,"t",$5 }'
else
df -h | tail -n +2 | awk '{ print $1,"t",$5 }'
fi
}

usage(){
echo "script usage: $(basename $0) [-h] [-p] [-m mount_point]" >&2
}

# If the user doesn't supply any arguments, we run the script as normal
if [ $# -eq 0 ];
then
get_percent
exit 0
fi
# ...


The Output



$ bash thing.sh
thing.sh: line 8: $1: unbound variable

$ bash -x thing.sh
+ set -e
+ set -u
+ set -o pipefail
+ '[' 0 -eq 0 ']'
+ get_percent
thing.sh: line 8: $1: unbound variable









share|improve this question

























  • I don't think this has anything to do with getopts, does it? Your script exits due to -u before calling getopts.

    – ilkkachu
    Aug 16 '18 at 18:31











  • @ikkachu no I guess it doesn't. But I'm not sure I can change the title now.

    – Timothy Pulliam
    Aug 16 '18 at 18:33











  • There should be that small "edit" text under the post, just beneath the tags in a question

    – ilkkachu
    Aug 16 '18 at 18:36














2












2








2








I am trying to learn how to use getopts so that I can have scripts with parsed input (although I think getopts could be better). I am trying to just write a simple script to return partition usage percentages. The problem is that one of my bash functions does not seem to like that I reference $1 as an variable within the function. The reason I reference $1 is because the get_percent function can be passed a mount point as an optional argument to display instead of all of the mount points.



The script



#!/usr/bin/bash

set -e
set -u
set -o pipefail

get_percent(){
if [ -n "$1" ]
then
df -h $1 | tail -n +2 | awk '{ print $1,"t",$5 }'
else
df -h | tail -n +2 | awk '{ print $1,"t",$5 }'
fi
}

usage(){
echo "script usage: $(basename $0) [-h] [-p] [-m mount_point]" >&2
}

# If the user doesn't supply any arguments, we run the script as normal
if [ $# -eq 0 ];
then
get_percent
exit 0
fi
# ...


The Output



$ bash thing.sh
thing.sh: line 8: $1: unbound variable

$ bash -x thing.sh
+ set -e
+ set -u
+ set -o pipefail
+ '[' 0 -eq 0 ']'
+ get_percent
thing.sh: line 8: $1: unbound variable









share|improve this question
















I am trying to learn how to use getopts so that I can have scripts with parsed input (although I think getopts could be better). I am trying to just write a simple script to return partition usage percentages. The problem is that one of my bash functions does not seem to like that I reference $1 as an variable within the function. The reason I reference $1 is because the get_percent function can be passed a mount point as an optional argument to display instead of all of the mount points.



The script



#!/usr/bin/bash

set -e
set -u
set -o pipefail

get_percent(){
if [ -n "$1" ]
then
df -h $1 | tail -n +2 | awk '{ print $1,"t",$5 }'
else
df -h | tail -n +2 | awk '{ print $1,"t",$5 }'
fi
}

usage(){
echo "script usage: $(basename $0) [-h] [-p] [-m mount_point]" >&2
}

# If the user doesn't supply any arguments, we run the script as normal
if [ $# -eq 0 ];
then
get_percent
exit 0
fi
# ...


The Output



$ bash thing.sh
thing.sh: line 8: $1: unbound variable

$ bash -x thing.sh
+ set -e
+ set -u
+ set -o pipefail
+ '[' 0 -eq 0 ']'
+ get_percent
thing.sh: line 8: $1: unbound variable






bash shell-script scripting






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 20 '18 at 22:27









Rui F Ribeiro

41.9k1483142




41.9k1483142










asked Aug 16 '18 at 18:00









Timothy PulliamTimothy Pulliam

1,3851025




1,3851025













  • I don't think this has anything to do with getopts, does it? Your script exits due to -u before calling getopts.

    – ilkkachu
    Aug 16 '18 at 18:31











  • @ikkachu no I guess it doesn't. But I'm not sure I can change the title now.

    – Timothy Pulliam
    Aug 16 '18 at 18:33











  • There should be that small "edit" text under the post, just beneath the tags in a question

    – ilkkachu
    Aug 16 '18 at 18:36



















  • I don't think this has anything to do with getopts, does it? Your script exits due to -u before calling getopts.

    – ilkkachu
    Aug 16 '18 at 18:31











  • @ikkachu no I guess it doesn't. But I'm not sure I can change the title now.

    – Timothy Pulliam
    Aug 16 '18 at 18:33











  • There should be that small "edit" text under the post, just beneath the tags in a question

    – ilkkachu
    Aug 16 '18 at 18:36

















I don't think this has anything to do with getopts, does it? Your script exits due to -u before calling getopts.

– ilkkachu
Aug 16 '18 at 18:31





I don't think this has anything to do with getopts, does it? Your script exits due to -u before calling getopts.

– ilkkachu
Aug 16 '18 at 18:31













@ikkachu no I guess it doesn't. But I'm not sure I can change the title now.

– Timothy Pulliam
Aug 16 '18 at 18:33





@ikkachu no I guess it doesn't. But I'm not sure I can change the title now.

– Timothy Pulliam
Aug 16 '18 at 18:33













There should be that small "edit" text under the post, just beneath the tags in a question

– ilkkachu
Aug 16 '18 at 18:36





There should be that small "edit" text under the post, just beneath the tags in a question

– ilkkachu
Aug 16 '18 at 18:36










4 Answers
4






active

oldest

votes


















14














set -u will abort exactly as you describe if you reference a variable which has not been set. You are invoking your script with no arguments, so get_percent is being invoked with no arguments, causing $1 to be unset.



Either check for this before invoking your function, or use default expansions (${1-default} will expand to default if not already set to something else).






share|improve this answer
























  • I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

    – Timothy Pulliam
    Aug 16 '18 at 18:10






  • 2





    In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

    – ilkkachu
    Aug 16 '18 at 18:30



















2














This is the effect of set -u.



You could check $# inside the function and avoid referencing $1 if it is not set.






share|improve this answer































    0














    Since this is bash you can sidestep the check for $1 being set and just use "$@" (when double-quoted, this parameter disappears completely if it has no values, which avoids it being caught by set -u):



    get_percent() {
    df -h "$@" | awk 'NR>1 { printf "%st%sn", $1, $5 }'
    }


    I've also tweaked the rest of the line slightly so that you don't get {space}{tab}{space} between the two values you output but insead you get just a {tab}. If you really want the two invisible spaces then change the awk to use printf "%s t %sn", $1, $5.






    share|improve this answer
























    • I will have to look into this. I'm not familiar with that variable type. Thanks

      – Timothy Pulliam
      Aug 16 '18 at 18:29





















    0














    Your key problem is here:



    if [ -n "$1" ] 


    By wrapping $1 in quotes, you're asking bash to perform string interpolation before it evaluates the -n operator.



    Instead, what you want is more like this:



    if [ -n $1 ]


    This allow bash to directly inspect the variable, without it being packed up in another expression first.



    Since you're already using bash, and have tossed compatibility with sh out the window, you should probably take this one step further:



    if [[ -n $1 ]]


    This is because [ is probably an actual binary on your system, and if bash finds [ in your PATH, it will use that [, not its builtin implementation. You won't have this problem with [[, so you know it's bash's implementation that gets used, and you know that it's the same version of bash that's running the rest of your script. (This might seem like a nonissue, but there are scenarios where multiple versions of bash might exist on the same system. Most commonly with Chef Habitat, but I'm sure it also happens in various cobbled sandbox environments, too.)



    Finally, for stylistic reasons, I'd suggest



    if [[ -n ${1} ]]


    as the preferred form. The reason for the {...} is because it makes it easier to reference arguments beyond ${9}. ${10} works, $10 doesn't.






    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%2f463034%2fbash-throws-error-line-8-1-unbound-variable%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      14














      set -u will abort exactly as you describe if you reference a variable which has not been set. You are invoking your script with no arguments, so get_percent is being invoked with no arguments, causing $1 to be unset.



      Either check for this before invoking your function, or use default expansions (${1-default} will expand to default if not already set to something else).






      share|improve this answer
























      • I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

        – Timothy Pulliam
        Aug 16 '18 at 18:10






      • 2





        In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

        – ilkkachu
        Aug 16 '18 at 18:30
















      14














      set -u will abort exactly as you describe if you reference a variable which has not been set. You are invoking your script with no arguments, so get_percent is being invoked with no arguments, causing $1 to be unset.



      Either check for this before invoking your function, or use default expansions (${1-default} will expand to default if not already set to something else).






      share|improve this answer
























      • I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

        – Timothy Pulliam
        Aug 16 '18 at 18:10






      • 2





        In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

        – ilkkachu
        Aug 16 '18 at 18:30














      14












      14








      14







      set -u will abort exactly as you describe if you reference a variable which has not been set. You are invoking your script with no arguments, so get_percent is being invoked with no arguments, causing $1 to be unset.



      Either check for this before invoking your function, or use default expansions (${1-default} will expand to default if not already set to something else).






      share|improve this answer













      set -u will abort exactly as you describe if you reference a variable which has not been set. You are invoking your script with no arguments, so get_percent is being invoked with no arguments, causing $1 to be unset.



      Either check for this before invoking your function, or use default expansions (${1-default} will expand to default if not already set to something else).







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Aug 16 '18 at 18:04









      DopeGhotiDopeGhoti

      46.7k56190




      46.7k56190













      • I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

        – Timothy Pulliam
        Aug 16 '18 at 18:10






      • 2





        In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

        – ilkkachu
        Aug 16 '18 at 18:30



















      • I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

        – Timothy Pulliam
        Aug 16 '18 at 18:10






      • 2





        In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

        – ilkkachu
        Aug 16 '18 at 18:30

















      I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

      – Timothy Pulliam
      Aug 16 '18 at 18:10





      I suspected this, but I couldn't think of a way around it. Default expansion seems to have fixed it. Thank you very much!

      – Timothy Pulliam
      Aug 16 '18 at 18:10




      2




      2





      In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

      – ilkkachu
      Aug 16 '18 at 18:30





      In particular, one could use [ -n "${1-}" ] (that is, with an empty default value) to see if the parameter is set and non-empty; or [ "${1+x}" = x ] to see if it's set, even if empty.

      – ilkkachu
      Aug 16 '18 at 18:30













      2














      This is the effect of set -u.



      You could check $# inside the function and avoid referencing $1 if it is not set.






      share|improve this answer




























        2














        This is the effect of set -u.



        You could check $# inside the function and avoid referencing $1 if it is not set.






        share|improve this answer


























          2












          2








          2







          This is the effect of set -u.



          You could check $# inside the function and avoid referencing $1 if it is not set.






          share|improve this answer













          This is the effect of set -u.



          You could check $# inside the function and avoid referencing $1 if it is not set.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Aug 16 '18 at 18:04









          RalfFriedlRalfFriedl

          5,44031025




          5,44031025























              0














              Since this is bash you can sidestep the check for $1 being set and just use "$@" (when double-quoted, this parameter disappears completely if it has no values, which avoids it being caught by set -u):



              get_percent() {
              df -h "$@" | awk 'NR>1 { printf "%st%sn", $1, $5 }'
              }


              I've also tweaked the rest of the line slightly so that you don't get {space}{tab}{space} between the two values you output but insead you get just a {tab}. If you really want the two invisible spaces then change the awk to use printf "%s t %sn", $1, $5.






              share|improve this answer
























              • I will have to look into this. I'm not familiar with that variable type. Thanks

                – Timothy Pulliam
                Aug 16 '18 at 18:29


















              0














              Since this is bash you can sidestep the check for $1 being set and just use "$@" (when double-quoted, this parameter disappears completely if it has no values, which avoids it being caught by set -u):



              get_percent() {
              df -h "$@" | awk 'NR>1 { printf "%st%sn", $1, $5 }'
              }


              I've also tweaked the rest of the line slightly so that you don't get {space}{tab}{space} between the two values you output but insead you get just a {tab}. If you really want the two invisible spaces then change the awk to use printf "%s t %sn", $1, $5.






              share|improve this answer
























              • I will have to look into this. I'm not familiar with that variable type. Thanks

                – Timothy Pulliam
                Aug 16 '18 at 18:29
















              0












              0








              0







              Since this is bash you can sidestep the check for $1 being set and just use "$@" (when double-quoted, this parameter disappears completely if it has no values, which avoids it being caught by set -u):



              get_percent() {
              df -h "$@" | awk 'NR>1 { printf "%st%sn", $1, $5 }'
              }


              I've also tweaked the rest of the line slightly so that you don't get {space}{tab}{space} between the two values you output but insead you get just a {tab}. If you really want the two invisible spaces then change the awk to use printf "%s t %sn", $1, $5.






              share|improve this answer













              Since this is bash you can sidestep the check for $1 being set and just use "$@" (when double-quoted, this parameter disappears completely if it has no values, which avoids it being caught by set -u):



              get_percent() {
              df -h "$@" | awk 'NR>1 { printf "%st%sn", $1, $5 }'
              }


              I've also tweaked the rest of the line slightly so that you don't get {space}{tab}{space} between the two values you output but insead you get just a {tab}. If you really want the two invisible spaces then change the awk to use printf "%s t %sn", $1, $5.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Aug 16 '18 at 18:14









              roaimaroaima

              45.9k758124




              45.9k758124













              • I will have to look into this. I'm not familiar with that variable type. Thanks

                – Timothy Pulliam
                Aug 16 '18 at 18:29





















              • I will have to look into this. I'm not familiar with that variable type. Thanks

                – Timothy Pulliam
                Aug 16 '18 at 18:29



















              I will have to look into this. I'm not familiar with that variable type. Thanks

              – Timothy Pulliam
              Aug 16 '18 at 18:29







              I will have to look into this. I'm not familiar with that variable type. Thanks

              – Timothy Pulliam
              Aug 16 '18 at 18:29













              0














              Your key problem is here:



              if [ -n "$1" ] 


              By wrapping $1 in quotes, you're asking bash to perform string interpolation before it evaluates the -n operator.



              Instead, what you want is more like this:



              if [ -n $1 ]


              This allow bash to directly inspect the variable, without it being packed up in another expression first.



              Since you're already using bash, and have tossed compatibility with sh out the window, you should probably take this one step further:



              if [[ -n $1 ]]


              This is because [ is probably an actual binary on your system, and if bash finds [ in your PATH, it will use that [, not its builtin implementation. You won't have this problem with [[, so you know it's bash's implementation that gets used, and you know that it's the same version of bash that's running the rest of your script. (This might seem like a nonissue, but there are scenarios where multiple versions of bash might exist on the same system. Most commonly with Chef Habitat, but I'm sure it also happens in various cobbled sandbox environments, too.)



              Finally, for stylistic reasons, I'd suggest



              if [[ -n ${1} ]]


              as the preferred form. The reason for the {...} is because it makes it easier to reference arguments beyond ${9}. ${10} works, $10 doesn't.






              share|improve this answer




























                0














                Your key problem is here:



                if [ -n "$1" ] 


                By wrapping $1 in quotes, you're asking bash to perform string interpolation before it evaluates the -n operator.



                Instead, what you want is more like this:



                if [ -n $1 ]


                This allow bash to directly inspect the variable, without it being packed up in another expression first.



                Since you're already using bash, and have tossed compatibility with sh out the window, you should probably take this one step further:



                if [[ -n $1 ]]


                This is because [ is probably an actual binary on your system, and if bash finds [ in your PATH, it will use that [, not its builtin implementation. You won't have this problem with [[, so you know it's bash's implementation that gets used, and you know that it's the same version of bash that's running the rest of your script. (This might seem like a nonissue, but there are scenarios where multiple versions of bash might exist on the same system. Most commonly with Chef Habitat, but I'm sure it also happens in various cobbled sandbox environments, too.)



                Finally, for stylistic reasons, I'd suggest



                if [[ -n ${1} ]]


                as the preferred form. The reason for the {...} is because it makes it easier to reference arguments beyond ${9}. ${10} works, $10 doesn't.






                share|improve this answer


























                  0












                  0








                  0







                  Your key problem is here:



                  if [ -n "$1" ] 


                  By wrapping $1 in quotes, you're asking bash to perform string interpolation before it evaluates the -n operator.



                  Instead, what you want is more like this:



                  if [ -n $1 ]


                  This allow bash to directly inspect the variable, without it being packed up in another expression first.



                  Since you're already using bash, and have tossed compatibility with sh out the window, you should probably take this one step further:



                  if [[ -n $1 ]]


                  This is because [ is probably an actual binary on your system, and if bash finds [ in your PATH, it will use that [, not its builtin implementation. You won't have this problem with [[, so you know it's bash's implementation that gets used, and you know that it's the same version of bash that's running the rest of your script. (This might seem like a nonissue, but there are scenarios where multiple versions of bash might exist on the same system. Most commonly with Chef Habitat, but I'm sure it also happens in various cobbled sandbox environments, too.)



                  Finally, for stylistic reasons, I'd suggest



                  if [[ -n ${1} ]]


                  as the preferred form. The reason for the {...} is because it makes it easier to reference arguments beyond ${9}. ${10} works, $10 doesn't.






                  share|improve this answer













                  Your key problem is here:



                  if [ -n "$1" ] 


                  By wrapping $1 in quotes, you're asking bash to perform string interpolation before it evaluates the -n operator.



                  Instead, what you want is more like this:



                  if [ -n $1 ]


                  This allow bash to directly inspect the variable, without it being packed up in another expression first.



                  Since you're already using bash, and have tossed compatibility with sh out the window, you should probably take this one step further:



                  if [[ -n $1 ]]


                  This is because [ is probably an actual binary on your system, and if bash finds [ in your PATH, it will use that [, not its builtin implementation. You won't have this problem with [[, so you know it's bash's implementation that gets used, and you know that it's the same version of bash that's running the rest of your script. (This might seem like a nonissue, but there are scenarios where multiple versions of bash might exist on the same system. Most commonly with Chef Habitat, but I'm sure it also happens in various cobbled sandbox environments, too.)



                  Finally, for stylistic reasons, I'd suggest



                  if [[ -n ${1} ]]


                  as the preferred form. The reason for the {...} is because it makes it easier to reference arguments beyond ${9}. ${10} works, $10 doesn't.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 16 mins ago









                  Michael MolMichael Mol

                  807515




                  807515






























                      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%2f463034%2fbash-throws-error-line-8-1-unbound-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

                      CARDNET

                      Boot-repair Failure: Unable to locate package grub-common:i386

                      濃尾地震