Variable with quotation marks “$()” Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)What is the point of the bash Null-operator “:”, colon?Why does bash remove n in $(cat file)?What other bash variables are available during execution such as $USER that can assist on my script?Problem with script substitution when running scriptChange Gsetting with script on LogoutHow to link a custom keyboard shortcut to a bash script in Ubuntu 13.04?Can you help me to understand this explanation of shell quoting?Installing breach browserhow to fix my keyboard after a bash script messed it up[Edited/include]man: bash. e and bash shell “enter” tokenusing variable within quotation marksHow to get BASH to use * wildcard in command?

Extracting terms with certain heads in a function

Is there such thing as an Availability Group failover trigger?

Irreducible of finite Krull dimension implies quasi-compact?

Amount of permutations on an NxNxN Rubik's Cube

What does "lightly crushed" mean for cardamon pods?

Delete nth line from bottom

Fundamental Solution of the Pell Equation

How to find all the available tools in mac terminal?

Why didn't Eitri join the fight?

How do I make this wiring inside cabinet safer? (Pic)

Why are there no cargo aircraft with "flying wing" design?

An adverb for when you're not exaggerating

How do I stop a creek from eroding my steep embankment?

If a VARCHAR(MAX) column is included in an index, is the entire value always stored in the index page(s)?

Why aren't air breathing engines used as small first stages

How to show element name in portuguese using elements package?

Generate an RGB colour grid

Compare a given version number in the form major.minor.build.patch and see if one is less than the other

What is the longest distance a player character can jump in one leap?

How does the math work when buying airline miles?

What is the escape velocity of a neutron particle (not neutron star)

How do I find out the mythology and history of my Fortress?

Does classifying an integer as a discrete log require it be part of a multiplicative group?

Can anything be seen from the center of the Boötes void? How dark would it be?



Variable with quotation marks “$()”



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)What is the point of the bash Null-operator “:”, colon?Why does bash remove n in $(cat file)?What other bash variables are available during execution such as $USER that can assist on my script?Problem with script substitution when running scriptChange Gsetting with script on LogoutHow to link a custom keyboard shortcut to a bash script in Ubuntu 13.04?Can you help me to understand this explanation of shell quoting?Installing breach browserhow to fix my keyboard after a bash script messed it up[Edited/include]man: bash. e and bash shell “enter” tokenusing variable within quotation marksHow to get BASH to use * wildcard in command?



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








12















I wrote this script :



#!/bin/bash
while [ true ]
do
currentoutput="$(lsusb)"
if [ "$currentoutput" != "$lastoutput" ]
then
echo "" date and Time >> test.log
date +%x_r >> test.log
lastoutput="$(lsusb)"
lsusb >> test.log
fi
sleep 5
done


I'm a newbie trying to learn fast and I got a question about the variable’s quotation marks.



Put a variable between $(), I get it, but why are the quotation marks needed even in the if statement? Is it to make a nested command?










share|improve this question









New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 5





    Note that while [ true ] does produce an infinite loop, but perhaps not for the reason you think it does; while [ false ] also produces an infinite loop, because with a single argument, [ ... ] succeeds if that argument is a non-empty string. while true will actually run a command named true (which always succeeds).

    – chepner
    Apr 12 at 13:06






  • 4





    You don't put a variable inside $(). You put a command inside $().

    – Wildcard
    Apr 12 at 20:19

















12















I wrote this script :



#!/bin/bash
while [ true ]
do
currentoutput="$(lsusb)"
if [ "$currentoutput" != "$lastoutput" ]
then
echo "" date and Time >> test.log
date +%x_r >> test.log
lastoutput="$(lsusb)"
lsusb >> test.log
fi
sleep 5
done


I'm a newbie trying to learn fast and I got a question about the variable’s quotation marks.



Put a variable between $(), I get it, but why are the quotation marks needed even in the if statement? Is it to make a nested command?










share|improve this question









New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 5





    Note that while [ true ] does produce an infinite loop, but perhaps not for the reason you think it does; while [ false ] also produces an infinite loop, because with a single argument, [ ... ] succeeds if that argument is a non-empty string. while true will actually run a command named true (which always succeeds).

    – chepner
    Apr 12 at 13:06






  • 4





    You don't put a variable inside $(). You put a command inside $().

    – Wildcard
    Apr 12 at 20:19













12












12








12


1






I wrote this script :



#!/bin/bash
while [ true ]
do
currentoutput="$(lsusb)"
if [ "$currentoutput" != "$lastoutput" ]
then
echo "" date and Time >> test.log
date +%x_r >> test.log
lastoutput="$(lsusb)"
lsusb >> test.log
fi
sleep 5
done


I'm a newbie trying to learn fast and I got a question about the variable’s quotation marks.



Put a variable between $(), I get it, but why are the quotation marks needed even in the if statement? Is it to make a nested command?










share|improve this question









New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I wrote this script :



#!/bin/bash
while [ true ]
do
currentoutput="$(lsusb)"
if [ "$currentoutput" != "$lastoutput" ]
then
echo "" date and Time >> test.log
date +%x_r >> test.log
lastoutput="$(lsusb)"
lsusb >> test.log
fi
sleep 5
done


I'm a newbie trying to learn fast and I got a question about the variable’s quotation marks.



Put a variable between $(), I get it, but why are the quotation marks needed even in the if statement? Is it to make a nested command?







bash scripts






share|improve this question









New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Apr 12 at 6:57









dessert

25.6k674108




25.6k674108






New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Apr 12 at 5:11









ShankharaShankhara

614




614




New contributor




Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Shankhara is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







  • 5





    Note that while [ true ] does produce an infinite loop, but perhaps not for the reason you think it does; while [ false ] also produces an infinite loop, because with a single argument, [ ... ] succeeds if that argument is a non-empty string. while true will actually run a command named true (which always succeeds).

    – chepner
    Apr 12 at 13:06






  • 4





    You don't put a variable inside $(). You put a command inside $().

    – Wildcard
    Apr 12 at 20:19












  • 5





    Note that while [ true ] does produce an infinite loop, but perhaps not for the reason you think it does; while [ false ] also produces an infinite loop, because with a single argument, [ ... ] succeeds if that argument is a non-empty string. while true will actually run a command named true (which always succeeds).

    – chepner
    Apr 12 at 13:06






  • 4





    You don't put a variable inside $(). You put a command inside $().

    – Wildcard
    Apr 12 at 20:19







5




5





Note that while [ true ] does produce an infinite loop, but perhaps not for the reason you think it does; while [ false ] also produces an infinite loop, because with a single argument, [ ... ] succeeds if that argument is a non-empty string. while true will actually run a command named true (which always succeeds).

– chepner
Apr 12 at 13:06





Note that while [ true ] does produce an infinite loop, but perhaps not for the reason you think it does; while [ false ] also produces an infinite loop, because with a single argument, [ ... ] succeeds if that argument is a non-empty string. while true will actually run a command named true (which always succeeds).

– chepner
Apr 12 at 13:06




4




4





You don't put a variable inside $(). You put a command inside $().

– Wildcard
Apr 12 at 20:19





You don't put a variable inside $(). You put a command inside $().

– Wildcard
Apr 12 at 20:19










4 Answers
4






active

oldest

votes


















22














Quotation marks prevent "word splitting". That is: breaking down variables into multiple items at whitespace characters (or to be more exact, at spaces, tabs, and newlines as defined in the value of the default $IFS shell variable).



For example,



$ var="one two"
$ howmany() echo $#;
$ howmany $var
2
$ howmany "$var"
1


Here we define the howmany function which just lets us know how many positional parameters are given. As you can see, there are two items being passed to the variable, and with the quotes the text in the variable is treated as one unit.



This is important for accurate passing of information. For example, if the variable contains path to file, and the filename contains spaces anywhere in the path, the command you are trying to run may fail or give inaccurate results. If we were trying to create a file with the $var variable, touch $var would create two files, but touch "$var" just one.



Same goes for your [ "$currentoutput" != "$lastoutput" ] part. This particular test performs a comparison on two strings. When the test runs, the [ command would need to see 3 arguments - a text string, the != operator, and another text string. Keeping double quotes prevents word splitting, and the [ command sees exactly those 3 arguments. Now what happens if variables are unquoted ?



$ var="hello world"
$ foo="hi world"
$ [ $var != $foo ]
bash: [: too many arguments
$


Here, word splitting occurs, and instead [ sees two strings hello and world followed by !=, followed by two other strings hi world. Key point is that without double quotes, the contents of variables are understood as separate units rather than one whole item.



Assigning command substitution doesn't require double quotes as in



var=$( df )


where you have the df command's output saved to var. However, it is a good habit to always double quote variables and command substitution $(...) unless you do in fact want the output to be treated as separate items.




On a side note, the



while [ true ]


part can be



while true


[ is a command which evaluates its arguments, and [ whatever ] is always true regardless of what is inside. By contrast, while true uses the command true which always returns success exit status (and that's exactly what while loop needs). The difference is a bit more clarity and less testing performed. Alternatively, you could also use : instead of true



The double quotes in echo "" date and Time part could probably be removed. They merely insert an empty string and an add extra space to the output. If that's desired, feel free to keep them there, but there's no particular functional value in this case.



lsusb >> test.log


This part could probably be replaced with echo "$currentoutput" >> test.log. There's no reason to run lsusb again after it has been run already in currentoutput=$(lsusb). In cases where trailing newlines
have to be preserved in the output - one could see the value in running a command multiple times, but in case of lsusb there's no need for that. The less external commands you call, the better, because every call to a non-built-in command incurs costs in CPU, memory usage, and execution time ( even though the commands are probably pre-loaded from memory).




See also:



  • When is double-quoting necessary?

  • What is the point of the bash null operator : (colon)?

  • Security implications of forgetting to quote a variable in bash/POSIX shells





share|improve this answer




















  • 1





    Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

    – RoVo
    Apr 12 at 7:05







  • 2





    @RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

    – Sergiy Kolodyazhnyy
    Apr 12 at 13:26






  • 1





    @SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

    – Charles Duffy
    Apr 12 at 16:13



















4














In currentoutput="$(lsusb)" lsusb is not a variable, it is a command. What this statement does, it executes lsusb command and assigns its output to currentoutput variable.



Older syntax for this was



currentoutput=`lsusb`


you can find it in many examples and scripts



To answer the other part of your question, if [ ] is just how syntax for if is defined in bash. See more in https://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.html






share|improve this answer


















  • 3





    I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

    – Arronical
    Apr 12 at 9:08











  • ...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

    – Charles Duffy
    Apr 12 at 16:16



















4














The following runs the external command command and returns its output.



"$(command)"


Without the brackets/parentheses, this would look for a variable instead of running a command:



"$variable"


As for the difference between $variable and "$variable", this becomes relevant when $variable contains spaces. When using "$variable", the entire variable contents will be inserted into a single string even if the contents include spaces. When using $variable the contents of the variable may be expanded into an argument list of multiple arguments.






share|improve this answer

























  • HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

    – Shankhara
    Apr 12 at 5:17


















0














To be contrarian - bash recommends you use the [[ ... ]] over the [ ... ] construct to avoid having to quote variables in the test and so the associated problems of word splitting that the others have pointed out.



[ is provided in bash for POSIX compatibility with scripts meant to run under #!/bin/sh or those being ported over to bash - for the most part, you should avoid it in favour of [[.



e.g.



# With [ - quotes are needed

$ foo='one two'; bar='one two'; [ $foo = $bar ] && echo "they're equal"
-bash: [: too many arguments

$ foo='one two'; bar='one two'; [ "$foo" = "$bar" ] && echo "they're equal"
they're equal

# versus [[ - quotes not needed

$ foo='one two'; bar='one two'; [[ $foo = $bar ]] && echo "they're equal"
they're equal






share|improve this answer























  • bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

    – chepner
    Apr 12 at 13:01











  • @chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

    – shalomb
    Apr 12 at 14:36











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
);



);






Shankhara is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1133173%2fvariable-with-quotation-marks%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









22














Quotation marks prevent "word splitting". That is: breaking down variables into multiple items at whitespace characters (or to be more exact, at spaces, tabs, and newlines as defined in the value of the default $IFS shell variable).



For example,



$ var="one two"
$ howmany() echo $#;
$ howmany $var
2
$ howmany "$var"
1


Here we define the howmany function which just lets us know how many positional parameters are given. As you can see, there are two items being passed to the variable, and with the quotes the text in the variable is treated as one unit.



This is important for accurate passing of information. For example, if the variable contains path to file, and the filename contains spaces anywhere in the path, the command you are trying to run may fail or give inaccurate results. If we were trying to create a file with the $var variable, touch $var would create two files, but touch "$var" just one.



Same goes for your [ "$currentoutput" != "$lastoutput" ] part. This particular test performs a comparison on two strings. When the test runs, the [ command would need to see 3 arguments - a text string, the != operator, and another text string. Keeping double quotes prevents word splitting, and the [ command sees exactly those 3 arguments. Now what happens if variables are unquoted ?



$ var="hello world"
$ foo="hi world"
$ [ $var != $foo ]
bash: [: too many arguments
$


Here, word splitting occurs, and instead [ sees two strings hello and world followed by !=, followed by two other strings hi world. Key point is that without double quotes, the contents of variables are understood as separate units rather than one whole item.



Assigning command substitution doesn't require double quotes as in



var=$( df )


where you have the df command's output saved to var. However, it is a good habit to always double quote variables and command substitution $(...) unless you do in fact want the output to be treated as separate items.




On a side note, the



while [ true ]


part can be



while true


[ is a command which evaluates its arguments, and [ whatever ] is always true regardless of what is inside. By contrast, while true uses the command true which always returns success exit status (and that's exactly what while loop needs). The difference is a bit more clarity and less testing performed. Alternatively, you could also use : instead of true



The double quotes in echo "" date and Time part could probably be removed. They merely insert an empty string and an add extra space to the output. If that's desired, feel free to keep them there, but there's no particular functional value in this case.



lsusb >> test.log


This part could probably be replaced with echo "$currentoutput" >> test.log. There's no reason to run lsusb again after it has been run already in currentoutput=$(lsusb). In cases where trailing newlines
have to be preserved in the output - one could see the value in running a command multiple times, but in case of lsusb there's no need for that. The less external commands you call, the better, because every call to a non-built-in command incurs costs in CPU, memory usage, and execution time ( even though the commands are probably pre-loaded from memory).




See also:



  • When is double-quoting necessary?

  • What is the point of the bash null operator : (colon)?

  • Security implications of forgetting to quote a variable in bash/POSIX shells





share|improve this answer




















  • 1





    Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

    – RoVo
    Apr 12 at 7:05







  • 2





    @RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

    – Sergiy Kolodyazhnyy
    Apr 12 at 13:26






  • 1





    @SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

    – Charles Duffy
    Apr 12 at 16:13
















22














Quotation marks prevent "word splitting". That is: breaking down variables into multiple items at whitespace characters (or to be more exact, at spaces, tabs, and newlines as defined in the value of the default $IFS shell variable).



For example,



$ var="one two"
$ howmany() echo $#;
$ howmany $var
2
$ howmany "$var"
1


Here we define the howmany function which just lets us know how many positional parameters are given. As you can see, there are two items being passed to the variable, and with the quotes the text in the variable is treated as one unit.



This is important for accurate passing of information. For example, if the variable contains path to file, and the filename contains spaces anywhere in the path, the command you are trying to run may fail or give inaccurate results. If we were trying to create a file with the $var variable, touch $var would create two files, but touch "$var" just one.



Same goes for your [ "$currentoutput" != "$lastoutput" ] part. This particular test performs a comparison on two strings. When the test runs, the [ command would need to see 3 arguments - a text string, the != operator, and another text string. Keeping double quotes prevents word splitting, and the [ command sees exactly those 3 arguments. Now what happens if variables are unquoted ?



$ var="hello world"
$ foo="hi world"
$ [ $var != $foo ]
bash: [: too many arguments
$


Here, word splitting occurs, and instead [ sees two strings hello and world followed by !=, followed by two other strings hi world. Key point is that without double quotes, the contents of variables are understood as separate units rather than one whole item.



Assigning command substitution doesn't require double quotes as in



var=$( df )


where you have the df command's output saved to var. However, it is a good habit to always double quote variables and command substitution $(...) unless you do in fact want the output to be treated as separate items.




On a side note, the



while [ true ]


part can be



while true


[ is a command which evaluates its arguments, and [ whatever ] is always true regardless of what is inside. By contrast, while true uses the command true which always returns success exit status (and that's exactly what while loop needs). The difference is a bit more clarity and less testing performed. Alternatively, you could also use : instead of true



The double quotes in echo "" date and Time part could probably be removed. They merely insert an empty string and an add extra space to the output. If that's desired, feel free to keep them there, but there's no particular functional value in this case.



lsusb >> test.log


This part could probably be replaced with echo "$currentoutput" >> test.log. There's no reason to run lsusb again after it has been run already in currentoutput=$(lsusb). In cases where trailing newlines
have to be preserved in the output - one could see the value in running a command multiple times, but in case of lsusb there's no need for that. The less external commands you call, the better, because every call to a non-built-in command incurs costs in CPU, memory usage, and execution time ( even though the commands are probably pre-loaded from memory).




See also:



  • When is double-quoting necessary?

  • What is the point of the bash null operator : (colon)?

  • Security implications of forgetting to quote a variable in bash/POSIX shells





share|improve this answer




















  • 1





    Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

    – RoVo
    Apr 12 at 7:05







  • 2





    @RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

    – Sergiy Kolodyazhnyy
    Apr 12 at 13:26






  • 1





    @SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

    – Charles Duffy
    Apr 12 at 16:13














22












22








22







Quotation marks prevent "word splitting". That is: breaking down variables into multiple items at whitespace characters (or to be more exact, at spaces, tabs, and newlines as defined in the value of the default $IFS shell variable).



For example,



$ var="one two"
$ howmany() echo $#;
$ howmany $var
2
$ howmany "$var"
1


Here we define the howmany function which just lets us know how many positional parameters are given. As you can see, there are two items being passed to the variable, and with the quotes the text in the variable is treated as one unit.



This is important for accurate passing of information. For example, if the variable contains path to file, and the filename contains spaces anywhere in the path, the command you are trying to run may fail or give inaccurate results. If we were trying to create a file with the $var variable, touch $var would create two files, but touch "$var" just one.



Same goes for your [ "$currentoutput" != "$lastoutput" ] part. This particular test performs a comparison on two strings. When the test runs, the [ command would need to see 3 arguments - a text string, the != operator, and another text string. Keeping double quotes prevents word splitting, and the [ command sees exactly those 3 arguments. Now what happens if variables are unquoted ?



$ var="hello world"
$ foo="hi world"
$ [ $var != $foo ]
bash: [: too many arguments
$


Here, word splitting occurs, and instead [ sees two strings hello and world followed by !=, followed by two other strings hi world. Key point is that without double quotes, the contents of variables are understood as separate units rather than one whole item.



Assigning command substitution doesn't require double quotes as in



var=$( df )


where you have the df command's output saved to var. However, it is a good habit to always double quote variables and command substitution $(...) unless you do in fact want the output to be treated as separate items.




On a side note, the



while [ true ]


part can be



while true


[ is a command which evaluates its arguments, and [ whatever ] is always true regardless of what is inside. By contrast, while true uses the command true which always returns success exit status (and that's exactly what while loop needs). The difference is a bit more clarity and less testing performed. Alternatively, you could also use : instead of true



The double quotes in echo "" date and Time part could probably be removed. They merely insert an empty string and an add extra space to the output. If that's desired, feel free to keep them there, but there's no particular functional value in this case.



lsusb >> test.log


This part could probably be replaced with echo "$currentoutput" >> test.log. There's no reason to run lsusb again after it has been run already in currentoutput=$(lsusb). In cases where trailing newlines
have to be preserved in the output - one could see the value in running a command multiple times, but in case of lsusb there's no need for that. The less external commands you call, the better, because every call to a non-built-in command incurs costs in CPU, memory usage, and execution time ( even though the commands are probably pre-loaded from memory).




See also:



  • When is double-quoting necessary?

  • What is the point of the bash null operator : (colon)?

  • Security implications of forgetting to quote a variable in bash/POSIX shells





share|improve this answer















Quotation marks prevent "word splitting". That is: breaking down variables into multiple items at whitespace characters (or to be more exact, at spaces, tabs, and newlines as defined in the value of the default $IFS shell variable).



For example,



$ var="one two"
$ howmany() echo $#;
$ howmany $var
2
$ howmany "$var"
1


Here we define the howmany function which just lets us know how many positional parameters are given. As you can see, there are two items being passed to the variable, and with the quotes the text in the variable is treated as one unit.



This is important for accurate passing of information. For example, if the variable contains path to file, and the filename contains spaces anywhere in the path, the command you are trying to run may fail or give inaccurate results. If we were trying to create a file with the $var variable, touch $var would create two files, but touch "$var" just one.



Same goes for your [ "$currentoutput" != "$lastoutput" ] part. This particular test performs a comparison on two strings. When the test runs, the [ command would need to see 3 arguments - a text string, the != operator, and another text string. Keeping double quotes prevents word splitting, and the [ command sees exactly those 3 arguments. Now what happens if variables are unquoted ?



$ var="hello world"
$ foo="hi world"
$ [ $var != $foo ]
bash: [: too many arguments
$


Here, word splitting occurs, and instead [ sees two strings hello and world followed by !=, followed by two other strings hi world. Key point is that without double quotes, the contents of variables are understood as separate units rather than one whole item.



Assigning command substitution doesn't require double quotes as in



var=$( df )


where you have the df command's output saved to var. However, it is a good habit to always double quote variables and command substitution $(...) unless you do in fact want the output to be treated as separate items.




On a side note, the



while [ true ]


part can be



while true


[ is a command which evaluates its arguments, and [ whatever ] is always true regardless of what is inside. By contrast, while true uses the command true which always returns success exit status (and that's exactly what while loop needs). The difference is a bit more clarity and less testing performed. Alternatively, you could also use : instead of true



The double quotes in echo "" date and Time part could probably be removed. They merely insert an empty string and an add extra space to the output. If that's desired, feel free to keep them there, but there's no particular functional value in this case.



lsusb >> test.log


This part could probably be replaced with echo "$currentoutput" >> test.log. There's no reason to run lsusb again after it has been run already in currentoutput=$(lsusb). In cases where trailing newlines
have to be preserved in the output - one could see the value in running a command multiple times, but in case of lsusb there's no need for that. The less external commands you call, the better, because every call to a non-built-in command incurs costs in CPU, memory usage, and execution time ( even though the commands are probably pre-loaded from memory).




See also:



  • When is double-quoting necessary?

  • What is the point of the bash null operator : (colon)?

  • Security implications of forgetting to quote a variable in bash/POSIX shells






share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 12 at 10:57









terdon

67.9k13140223




67.9k13140223










answered Apr 12 at 5:50









Sergiy KolodyazhnyySergiy Kolodyazhnyy

75.6k9156330




75.6k9156330







  • 1





    Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

    – RoVo
    Apr 12 at 7:05







  • 2





    @RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

    – Sergiy Kolodyazhnyy
    Apr 12 at 13:26






  • 1





    @SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

    – Charles Duffy
    Apr 12 at 16:13













  • 1





    Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

    – RoVo
    Apr 12 at 7:05







  • 2





    @RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

    – Sergiy Kolodyazhnyy
    Apr 12 at 13:26






  • 1





    @SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

    – Charles Duffy
    Apr 12 at 16:13








1




1





Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

– RoVo
Apr 12 at 7:05






Great answer, if you didn't already, you should write a book about bash. But in the last part shouldn't echo "$currentoutput" >> test.log better be printf '%sn' "$currentoutput" >> test.log ?

– RoVo
Apr 12 at 7:05





2




2





@RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

– Sergiy Kolodyazhnyy
Apr 12 at 13:26





@RoVo Yes, printf should be preferred for portability. Since we're using bash-specific script here it can be excused to use echo. But your observation is very much correct

– Sergiy Kolodyazhnyy
Apr 12 at 13:26




1




1





@SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

– Charles Duffy
Apr 12 at 16:13






@SergiyKolodyazhnyy, ...I'm not sure that echo is completely reliable even when the shell is known to be bash (and the value of the xpg_echo and posix flags is known); if your value could be -n or -e, it can disappear instead of being printed.

– Charles Duffy
Apr 12 at 16:13














4














In currentoutput="$(lsusb)" lsusb is not a variable, it is a command. What this statement does, it executes lsusb command and assigns its output to currentoutput variable.



Older syntax for this was



currentoutput=`lsusb`


you can find it in many examples and scripts



To answer the other part of your question, if [ ] is just how syntax for if is defined in bash. See more in https://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.html






share|improve this answer


















  • 3





    I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

    – Arronical
    Apr 12 at 9:08











  • ...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

    – Charles Duffy
    Apr 12 at 16:16
















4














In currentoutput="$(lsusb)" lsusb is not a variable, it is a command. What this statement does, it executes lsusb command and assigns its output to currentoutput variable.



Older syntax for this was



currentoutput=`lsusb`


you can find it in many examples and scripts



To answer the other part of your question, if [ ] is just how syntax for if is defined in bash. See more in https://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.html






share|improve this answer


















  • 3





    I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

    – Arronical
    Apr 12 at 9:08











  • ...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

    – Charles Duffy
    Apr 12 at 16:16














4












4








4







In currentoutput="$(lsusb)" lsusb is not a variable, it is a command. What this statement does, it executes lsusb command and assigns its output to currentoutput variable.



Older syntax for this was



currentoutput=`lsusb`


you can find it in many examples and scripts



To answer the other part of your question, if [ ] is just how syntax for if is defined in bash. See more in https://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.html






share|improve this answer













In currentoutput="$(lsusb)" lsusb is not a variable, it is a command. What this statement does, it executes lsusb command and assigns its output to currentoutput variable.



Older syntax for this was



currentoutput=`lsusb`


you can find it in many examples and scripts



To answer the other part of your question, if [ ] is just how syntax for if is defined in bash. See more in https://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.html







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 12 at 5:17









marosgmarosg

48437




48437







  • 3





    I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

    – Arronical
    Apr 12 at 9:08











  • ...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

    – Charles Duffy
    Apr 12 at 16:16













  • 3





    I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

    – Arronical
    Apr 12 at 9:08











  • ...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

    – Charles Duffy
    Apr 12 at 16:16








3




3





I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

– Arronical
Apr 12 at 9:08





I think it's important to say that [ ] is actually the test command. You can use if statements with other commands too, as it relies on a 0 or non-zero test of their exit code.

– Arronical
Apr 12 at 9:08













...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

– Charles Duffy
Apr 12 at 16:16






...indeed, it's much better to run if grep -qe "somestring" file than to run grep -qe "somestring" file; if [ $? = 0 ]; then ..., so the claim that if [ ... is part of the definition of if syntax is not just misleading but leads to bad practices.

– Charles Duffy
Apr 12 at 16:16












4














The following runs the external command command and returns its output.



"$(command)"


Without the brackets/parentheses, this would look for a variable instead of running a command:



"$variable"


As for the difference between $variable and "$variable", this becomes relevant when $variable contains spaces. When using "$variable", the entire variable contents will be inserted into a single string even if the contents include spaces. When using $variable the contents of the variable may be expanded into an argument list of multiple arguments.






share|improve this answer

























  • HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

    – Shankhara
    Apr 12 at 5:17















4














The following runs the external command command and returns its output.



"$(command)"


Without the brackets/parentheses, this would look for a variable instead of running a command:



"$variable"


As for the difference between $variable and "$variable", this becomes relevant when $variable contains spaces. When using "$variable", the entire variable contents will be inserted into a single string even if the contents include spaces. When using $variable the contents of the variable may be expanded into an argument list of multiple arguments.






share|improve this answer

























  • HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

    – Shankhara
    Apr 12 at 5:17













4












4








4







The following runs the external command command and returns its output.



"$(command)"


Without the brackets/parentheses, this would look for a variable instead of running a command:



"$variable"


As for the difference between $variable and "$variable", this becomes relevant when $variable contains spaces. When using "$variable", the entire variable contents will be inserted into a single string even if the contents include spaces. When using $variable the contents of the variable may be expanded into an argument list of multiple arguments.






share|improve this answer















The following runs the external command command and returns its output.



"$(command)"


Without the brackets/parentheses, this would look for a variable instead of running a command:



"$variable"


As for the difference between $variable and "$variable", this becomes relevant when $variable contains spaces. When using "$variable", the entire variable contents will be inserted into a single string even if the contents include spaces. When using $variable the contents of the variable may be expanded into an argument list of multiple arguments.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 12 at 5:18

























answered Apr 12 at 5:14









thomasrutterthomasrutter

27.4k47089




27.4k47089












  • HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

    – Shankhara
    Apr 12 at 5:17

















  • HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

    – Shankhara
    Apr 12 at 5:17
















HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

– Shankhara
Apr 12 at 5:17





HI @thomasrutter, I'm sorry, i meant quotation mark ... I edit my comment now !

– Shankhara
Apr 12 at 5:17











0














To be contrarian - bash recommends you use the [[ ... ]] over the [ ... ] construct to avoid having to quote variables in the test and so the associated problems of word splitting that the others have pointed out.



[ is provided in bash for POSIX compatibility with scripts meant to run under #!/bin/sh or those being ported over to bash - for the most part, you should avoid it in favour of [[.



e.g.



# With [ - quotes are needed

$ foo='one two'; bar='one two'; [ $foo = $bar ] && echo "they're equal"
-bash: [: too many arguments

$ foo='one two'; bar='one two'; [ "$foo" = "$bar" ] && echo "they're equal"
they're equal

# versus [[ - quotes not needed

$ foo='one two'; bar='one two'; [[ $foo = $bar ]] && echo "they're equal"
they're equal






share|improve this answer























  • bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

    – chepner
    Apr 12 at 13:01











  • @chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

    – shalomb
    Apr 12 at 14:36















0














To be contrarian - bash recommends you use the [[ ... ]] over the [ ... ] construct to avoid having to quote variables in the test and so the associated problems of word splitting that the others have pointed out.



[ is provided in bash for POSIX compatibility with scripts meant to run under #!/bin/sh or those being ported over to bash - for the most part, you should avoid it in favour of [[.



e.g.



# With [ - quotes are needed

$ foo='one two'; bar='one two'; [ $foo = $bar ] && echo "they're equal"
-bash: [: too many arguments

$ foo='one two'; bar='one two'; [ "$foo" = "$bar" ] && echo "they're equal"
they're equal

# versus [[ - quotes not needed

$ foo='one two'; bar='one two'; [[ $foo = $bar ]] && echo "they're equal"
they're equal






share|improve this answer























  • bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

    – chepner
    Apr 12 at 13:01











  • @chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

    – shalomb
    Apr 12 at 14:36













0












0








0







To be contrarian - bash recommends you use the [[ ... ]] over the [ ... ] construct to avoid having to quote variables in the test and so the associated problems of word splitting that the others have pointed out.



[ is provided in bash for POSIX compatibility with scripts meant to run under #!/bin/sh or those being ported over to bash - for the most part, you should avoid it in favour of [[.



e.g.



# With [ - quotes are needed

$ foo='one two'; bar='one two'; [ $foo = $bar ] && echo "they're equal"
-bash: [: too many arguments

$ foo='one two'; bar='one two'; [ "$foo" = "$bar" ] && echo "they're equal"
they're equal

# versus [[ - quotes not needed

$ foo='one two'; bar='one two'; [[ $foo = $bar ]] && echo "they're equal"
they're equal






share|improve this answer













To be contrarian - bash recommends you use the [[ ... ]] over the [ ... ] construct to avoid having to quote variables in the test and so the associated problems of word splitting that the others have pointed out.



[ is provided in bash for POSIX compatibility with scripts meant to run under #!/bin/sh or those being ported over to bash - for the most part, you should avoid it in favour of [[.



e.g.



# With [ - quotes are needed

$ foo='one two'; bar='one two'; [ $foo = $bar ] && echo "they're equal"
-bash: [: too many arguments

$ foo='one two'; bar='one two'; [ "$foo" = "$bar" ] && echo "they're equal"
they're equal

# versus [[ - quotes not needed

$ foo='one two'; bar='one two'; [[ $foo = $bar ]] && echo "they're equal"
they're equal







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 12 at 12:56









shalombshalomb

1814




1814












  • bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

    – chepner
    Apr 12 at 13:01











  • @chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

    – shalomb
    Apr 12 at 14:36

















  • bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

    – chepner
    Apr 12 at 13:01











  • @chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

    – shalomb
    Apr 12 at 14:36
















bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

– chepner
Apr 12 at 13:01





bash makes no such recommendation; it provides [[ ... ]] which can be more convenient and has some functionality that [ ... ] does not, but there is no problem with using [ ... ] correctly.

– chepner
Apr 12 at 13:01













@chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

– shalomb
Apr 12 at 14:36





@chepner - Maybe I should be clearer here. Sure it's not an explicit recommendation in the bash manpage but given [[ does everything [ does and more and still the many times [ trips people up and then try and retrofit features of [[ back to [ only to fail and leave bugs scattered about - it's fair to say it is a community recommendation in as far as most relevant bash style guides will advise never use [.

– shalomb
Apr 12 at 14:36










Shankhara is a new contributor. Be nice, and check out our Code of Conduct.









draft saved

draft discarded


















Shankhara is a new contributor. Be nice, and check out our Code of Conduct.












Shankhara is a new contributor. Be nice, and check out our Code of Conduct.











Shankhara is a new contributor. Be nice, and check out our Code of Conduct.














Thanks for contributing an answer to Ask Ubuntu!


  • 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%2faskubuntu.com%2fquestions%2f1133173%2fvariable-with-quotation-marks%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

Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020