Is `echo $TEST` expanding an asterisk in the variable a bug? [duplicate]Why does my shell script choke on whitespace or other special characters?Security implications of forgetting to quote a variable in bash/POSIX shellsWhen is double-quoting necessary?Why is bash extended-globbing variable substitution acting at the byte level?In bash, how can I echo the variable name, not the variable value?Why does `bash -c somecommand` sometimes not leave a bash process?Why does BASH process substitution not work with some commands?Bash regex string manipulation bugecho \* - bash backslash escape behavior, is it evaluated backwards?Why there is such a difference in execution time of echo and cat?Expanding a brace expansion string held in a variable for use in a for loop?have I found a bug in BASH?bash and expect in the same script?

Multi tool use
Multi tool use

Boss wants someone else to lead a project based on the idea I presented to him

Why isn't my calculation that we should be able to see the sun well beyond the observable universe valid?

Are there any individual aliens that have gained superpowers in the Marvel universe?

Justifying Affordable Bespoke Spaceships

Am I legally required to provide a (GPL licensed) source code even after a project is abandoned?

How did Gollum enter Moria?

What is the "ls" directory in my home directory?

Second 100 amp breaker inside existing 200 amp residential panel for new detached garage

Proving an Intuitive Result Rigorously

How do I remove this inheritance-related code smell?

Extending prime numbers digit by digit while retaining primality

Value matching with NA - missing values - using mutate

Should I include an appendix for inessential, yet related worldbuilding to my story?

Why don't we have a weaning party like Avraham did?

How could empty set be unique if it could be vacuously false

Designing a magic-compatible polearm

Cut the gold chain

Did the CIA blow up a Siberian pipeline in 1982?

Are there examples of rowers who also fought?

King or Queen-Which piece is which?

What triggered jesuits' ban on infinitesimals in 1632?

Dmesg full of I/O errors, smart ok, four disks affected

Why is oilcloth made with linseed oil?

What was the first third-party commercial application for MS-DOS?



Is `echo $TEST` expanding an asterisk in the variable a bug? [duplicate]


Why does my shell script choke on whitespace or other special characters?Security implications of forgetting to quote a variable in bash/POSIX shellsWhen is double-quoting necessary?Why is bash extended-globbing variable substitution acting at the byte level?In bash, how can I echo the variable name, not the variable value?Why does `bash -c somecommand` sometimes not leave a bash process?Why does BASH process substitution not work with some commands?Bash regex string manipulation bugecho \* - bash backslash escape behavior, is it evaluated backwards?Why there is such a difference in execution time of echo and cat?Expanding a brace expansion string held in a variable for use in a for loop?have I found a bug in BASH?bash and expect in the same script?






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








3
















This question already has an answer here:



  • Why does my shell script choke on whitespace or other special characters?

    4 answers



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

    3 answers



  • When is double-quoting necessary?

    1 answer



Is this a Bash bug?



$ mkdir test && cd test && echo "a" > "some.file"
test$ echo '*'
*
test$ TEST=$(echo '*')
test$ echo $TEST
some.file


Why is the second output the resolution of * into (all) filenames instead of just a literal * output? Looks like a bug in Bash?



Tried on Ubuntu 18.04, bash version 4.4.19(1)-release. Expect it will be the same on other OS'es.










share|improve this question















marked as duplicate by muru, Scott, ilkkachu bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Jun 3 at 19:08


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.













  • 2





    General procedure when finding bugs in Unix: 1) Check out Single Unix Specification online for relevant definitions and rationales. 2) Submit a bugreport to austingroupbugs.net 3) Submit bugreport to the developer (with a patch if possible).

    – DannyNiu
    Jun 3 at 1:10







  • 3





    @DannyNiu: Your comment is not very practical.  Documents like POSIX and the Single Unix Specification do not consist of millions and millions of examples; they contain explanations (with, maybe, a few examples).  Those documents are of little help to somebody who doesn’t understand what is happening and why; reading them is like learning to drive by reading a roadmap. And this question isn’t asking what to do.  If you want to post a question, “What should I do if I’ve found a bug in a widely used software product?”, and post an answer, go ahead.

    – G-Man
    Jun 3 at 4:26












  • @G-Man I did find DannyNiu's answer helpful in terms of the information provided, "just in case".

    – Roel
    Jun 3 at 4:28

















3
















This question already has an answer here:



  • Why does my shell script choke on whitespace or other special characters?

    4 answers



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

    3 answers



  • When is double-quoting necessary?

    1 answer



Is this a Bash bug?



$ mkdir test && cd test && echo "a" > "some.file"
test$ echo '*'
*
test$ TEST=$(echo '*')
test$ echo $TEST
some.file


Why is the second output the resolution of * into (all) filenames instead of just a literal * output? Looks like a bug in Bash?



Tried on Ubuntu 18.04, bash version 4.4.19(1)-release. Expect it will be the same on other OS'es.










share|improve this question















marked as duplicate by muru, Scott, ilkkachu bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Jun 3 at 19:08


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.













  • 2





    General procedure when finding bugs in Unix: 1) Check out Single Unix Specification online for relevant definitions and rationales. 2) Submit a bugreport to austingroupbugs.net 3) Submit bugreport to the developer (with a patch if possible).

    – DannyNiu
    Jun 3 at 1:10







  • 3





    @DannyNiu: Your comment is not very practical.  Documents like POSIX and the Single Unix Specification do not consist of millions and millions of examples; they contain explanations (with, maybe, a few examples).  Those documents are of little help to somebody who doesn’t understand what is happening and why; reading them is like learning to drive by reading a roadmap. And this question isn’t asking what to do.  If you want to post a question, “What should I do if I’ve found a bug in a widely used software product?”, and post an answer, go ahead.

    – G-Man
    Jun 3 at 4:26












  • @G-Man I did find DannyNiu's answer helpful in terms of the information provided, "just in case".

    – Roel
    Jun 3 at 4:28













3












3








3


1







This question already has an answer here:



  • Why does my shell script choke on whitespace or other special characters?

    4 answers



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

    3 answers



  • When is double-quoting necessary?

    1 answer



Is this a Bash bug?



$ mkdir test && cd test && echo "a" > "some.file"
test$ echo '*'
*
test$ TEST=$(echo '*')
test$ echo $TEST
some.file


Why is the second output the resolution of * into (all) filenames instead of just a literal * output? Looks like a bug in Bash?



Tried on Ubuntu 18.04, bash version 4.4.19(1)-release. Expect it will be the same on other OS'es.










share|improve this question

















This question already has an answer here:



  • Why does my shell script choke on whitespace or other special characters?

    4 answers



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

    3 answers



  • When is double-quoting necessary?

    1 answer



Is this a Bash bug?



$ mkdir test && cd test && echo "a" > "some.file"
test$ echo '*'
*
test$ TEST=$(echo '*')
test$ echo $TEST
some.file


Why is the second output the resolution of * into (all) filenames instead of just a literal * output? Looks like a bug in Bash?



Tried on Ubuntu 18.04, bash version 4.4.19(1)-release. Expect it will be the same on other OS'es.





This question already has an answer here:



  • Why does my shell script choke on whitespace or other special characters?

    4 answers



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

    3 answers



  • When is double-quoting necessary?

    1 answer







bash shell quoting command-substitution variable-substitution






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 3 at 18:00









Gilles

559k13411471657




559k13411471657










asked Jun 3 at 0:16









RoelRoel

1267




1267




marked as duplicate by muru, Scott, ilkkachu bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Jun 3 at 19:08


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









marked as duplicate by muru, Scott, ilkkachu bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Jun 3 at 19:08


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









  • 2





    General procedure when finding bugs in Unix: 1) Check out Single Unix Specification online for relevant definitions and rationales. 2) Submit a bugreport to austingroupbugs.net 3) Submit bugreport to the developer (with a patch if possible).

    – DannyNiu
    Jun 3 at 1:10







  • 3





    @DannyNiu: Your comment is not very practical.  Documents like POSIX and the Single Unix Specification do not consist of millions and millions of examples; they contain explanations (with, maybe, a few examples).  Those documents are of little help to somebody who doesn’t understand what is happening and why; reading them is like learning to drive by reading a roadmap. And this question isn’t asking what to do.  If you want to post a question, “What should I do if I’ve found a bug in a widely used software product?”, and post an answer, go ahead.

    – G-Man
    Jun 3 at 4:26












  • @G-Man I did find DannyNiu's answer helpful in terms of the information provided, "just in case".

    – Roel
    Jun 3 at 4:28












  • 2





    General procedure when finding bugs in Unix: 1) Check out Single Unix Specification online for relevant definitions and rationales. 2) Submit a bugreport to austingroupbugs.net 3) Submit bugreport to the developer (with a patch if possible).

    – DannyNiu
    Jun 3 at 1:10







  • 3





    @DannyNiu: Your comment is not very practical.  Documents like POSIX and the Single Unix Specification do not consist of millions and millions of examples; they contain explanations (with, maybe, a few examples).  Those documents are of little help to somebody who doesn’t understand what is happening and why; reading them is like learning to drive by reading a roadmap. And this question isn’t asking what to do.  If you want to post a question, “What should I do if I’ve found a bug in a widely used software product?”, and post an answer, go ahead.

    – G-Man
    Jun 3 at 4:26












  • @G-Man I did find DannyNiu's answer helpful in terms of the information provided, "just in case".

    – Roel
    Jun 3 at 4:28







2




2





General procedure when finding bugs in Unix: 1) Check out Single Unix Specification online for relevant definitions and rationales. 2) Submit a bugreport to austingroupbugs.net 3) Submit bugreport to the developer (with a patch if possible).

– DannyNiu
Jun 3 at 1:10






General procedure when finding bugs in Unix: 1) Check out Single Unix Specification online for relevant definitions and rationales. 2) Submit a bugreport to austingroupbugs.net 3) Submit bugreport to the developer (with a patch if possible).

– DannyNiu
Jun 3 at 1:10





3




3





@DannyNiu: Your comment is not very practical.  Documents like POSIX and the Single Unix Specification do not consist of millions and millions of examples; they contain explanations (with, maybe, a few examples).  Those documents are of little help to somebody who doesn’t understand what is happening and why; reading them is like learning to drive by reading a roadmap. And this question isn’t asking what to do.  If you want to post a question, “What should I do if I’ve found a bug in a widely used software product?”, and post an answer, go ahead.

– G-Man
Jun 3 at 4:26






@DannyNiu: Your comment is not very practical.  Documents like POSIX and the Single Unix Specification do not consist of millions and millions of examples; they contain explanations (with, maybe, a few examples).  Those documents are of little help to somebody who doesn’t understand what is happening and why; reading them is like learning to drive by reading a roadmap. And this question isn’t asking what to do.  If you want to post a question, “What should I do if I’ve found a bug in a widely used software product?”, and post an answer, go ahead.

– G-Man
Jun 3 at 4:26














@G-Man I did find DannyNiu's answer helpful in terms of the information provided, "just in case".

– Roel
Jun 3 at 4:28





@G-Man I did find DannyNiu's answer helpful in terms of the information provided, "just in case".

– Roel
Jun 3 at 4:28










1 Answer
1






active

oldest

votes


















13














No, it is not a bug. You have shown that



echo '*'


will produce a literal *. Hence when you substitute this output, as per the following command



TEST=$(echo '*')


it will put * into the variable $TEST. Then when you



echo $TEST


the glob will expand here. You can verify this by running this last command, changing directories, then running it again.



You will get the * output if you say



echo "$TEST"


as explained here,
the double quotes allow the variable to be expanded
but prevent the glob from expanding.






share|improve this answer

























  • Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

    – Roel
    Jun 3 at 1:36






  • 3





    @Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

    – slebetman
    Jun 3 at 9:24






  • 8





    And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

    – Muzer
    Jun 3 at 10:15






  • 2





    @slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

    – Piskvor
    Jun 3 at 12:42






  • 3





    @Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

    – RonJohn
    Jun 3 at 14:56


















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









13














No, it is not a bug. You have shown that



echo '*'


will produce a literal *. Hence when you substitute this output, as per the following command



TEST=$(echo '*')


it will put * into the variable $TEST. Then when you



echo $TEST


the glob will expand here. You can verify this by running this last command, changing directories, then running it again.



You will get the * output if you say



echo "$TEST"


as explained here,
the double quotes allow the variable to be expanded
but prevent the glob from expanding.






share|improve this answer

























  • Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

    – Roel
    Jun 3 at 1:36






  • 3





    @Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

    – slebetman
    Jun 3 at 9:24






  • 8





    And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

    – Muzer
    Jun 3 at 10:15






  • 2





    @slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

    – Piskvor
    Jun 3 at 12:42






  • 3





    @Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

    – RonJohn
    Jun 3 at 14:56
















13














No, it is not a bug. You have shown that



echo '*'


will produce a literal *. Hence when you substitute this output, as per the following command



TEST=$(echo '*')


it will put * into the variable $TEST. Then when you



echo $TEST


the glob will expand here. You can verify this by running this last command, changing directories, then running it again.



You will get the * output if you say



echo "$TEST"


as explained here,
the double quotes allow the variable to be expanded
but prevent the glob from expanding.






share|improve this answer

























  • Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

    – Roel
    Jun 3 at 1:36






  • 3





    @Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

    – slebetman
    Jun 3 at 9:24






  • 8





    And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

    – Muzer
    Jun 3 at 10:15






  • 2





    @slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

    – Piskvor
    Jun 3 at 12:42






  • 3





    @Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

    – RonJohn
    Jun 3 at 14:56














13












13








13







No, it is not a bug. You have shown that



echo '*'


will produce a literal *. Hence when you substitute this output, as per the following command



TEST=$(echo '*')


it will put * into the variable $TEST. Then when you



echo $TEST


the glob will expand here. You can verify this by running this last command, changing directories, then running it again.



You will get the * output if you say



echo "$TEST"


as explained here,
the double quotes allow the variable to be expanded
but prevent the glob from expanding.






share|improve this answer















No, it is not a bug. You have shown that



echo '*'


will produce a literal *. Hence when you substitute this output, as per the following command



TEST=$(echo '*')


it will put * into the variable $TEST. Then when you



echo $TEST


the glob will expand here. You can verify this by running this last command, changing directories, then running it again.



You will get the * output if you say



echo "$TEST"


as explained here,
the double quotes allow the variable to be expanded
but prevent the glob from expanding.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jun 3 at 4:37









G-Man

14.7k94175




14.7k94175










answered Jun 3 at 0:22









SparhawkSparhawk

10.8k849102




10.8k849102












  • Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

    – Roel
    Jun 3 at 1:36






  • 3





    @Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

    – slebetman
    Jun 3 at 9:24






  • 8





    And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

    – Muzer
    Jun 3 at 10:15






  • 2





    @slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

    – Piskvor
    Jun 3 at 12:42






  • 3





    @Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

    – RonJohn
    Jun 3 at 14:56


















  • Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

    – Roel
    Jun 3 at 1:36






  • 3





    @Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

    – slebetman
    Jun 3 at 9:24






  • 8





    And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

    – Muzer
    Jun 3 at 10:15






  • 2





    @slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

    – Piskvor
    Jun 3 at 12:42






  • 3





    @Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

    – RonJohn
    Jun 3 at 14:56

















Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

– Roel
Jun 3 at 1:36





Aha, I see. Thank you. I missed the fact that the echo * does not have quotes and thus resolves. It's harder to see when you have it inside a complex script :) Makes sense now.

– Roel
Jun 3 at 1:36




3




3





@Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

– slebetman
Jun 3 at 9:24





@Roel FWIW, after a few years of experience you will start to treat $TEST instead of "$TEST" as a code smell and it becomes a bit easier to see. It's still not much of a smell though so it will still trip you up sometimes

– slebetman
Jun 3 at 9:24




8




8





And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

– Muzer
Jun 3 at 10:15





And this is why my general approach is, if it starts with a dollar, quote it :). Yes, you CAN learn the specific cases where you don't have to - but it's almost always harmless to quote them in cases where you don't have to, so you may as well just quote your variables everywhere!

– Muzer
Jun 3 at 10:15




2




2





@slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

– Piskvor
Jun 3 at 12:42





@slebetman: And for the rest of us without this instinct, shellcheck will do the complaining ( shellcheck.net ).

– Piskvor
Jun 3 at 12:42




3




3





@Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

– RonJohn
Jun 3 at 14:56






@Roel many decades ago, I learned -- the hard way -- that 99.99999% of the time it's your fault, not a bug in the compiler or interpreter... :)

– RonJohn
Jun 3 at 14:56




RsL1hqpm6 TeXgdobst9y7Jf3qKwZc 4B1h9ckQ AyboC
glv7,RqcgAjgEUn raVBd7mNip0E Jyt8L1H4w90 Wg3 h3U9g,xO0KK,DT8VUsCNrU,W,Pgu,Ra0WnY m k

Popular posts from this blog

RemoteApp sporadic failureWindows 2008 RemoteAPP client disconnects within a matter of minutesWhat is the minimum version of RDP supported by Server 2012 RDS?How to configure a Remoteapp server to increase stabilityMicrosoft RemoteApp Active SessionRDWeb TS connection broken for some users post RemoteApp certificate changeRemote Desktop Licensing, RemoteAPPRDS 2012 R2 some users are not able to logon after changed date and time on Connection BrokersWhat happens during Remote Desktop logon, and is there any logging?After installing RDS on WinServer 2016 I still can only connect with two users?RD Connection via RDGW to Session host is not connecting

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