Prevent quote expansion in user-made function [duplicate]












1
















This question already has an answer here:




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

    4 answers



  • When is double-quoting necessary?

    1 answer




I have the following bash function :



tg() {

  git add -A && git commit -m $1 && git push

}


But it seems not to work :



$ tg "create index for users"

error: pathspec 'index' did not match any file(s) known to git.

error: pathspec 'for' did not match any file(s) known to git.

error: pathspec 'users' did not match any file(s) known to git.


Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



What did I do wrong ? How can I fix this ?






bash quoting







share|improve this question















marked as duplicate by 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();
}
);
});
});
 Jan 2 at 10:41


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.














  • 1





    Also: mywiki.wooledge.org/WordSplitting

    – ilkkachu
    Jan 2 at 10:47
















1
















This question already has an answer here:




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

    4 answers



  • When is double-quoting necessary?

    1 answer




I have the following bash function :



tg() {

  git add -A && git commit -m $1 && git push

}


But it seems not to work :



$ tg "create index for users"

error: pathspec 'index' did not match any file(s) known to git.

error: pathspec 'for' did not match any file(s) known to git.

error: pathspec 'users' did not match any file(s) known to git.


Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



What did I do wrong ? How can I fix this ?






bash quoting







share|improve this question















marked as duplicate by 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();
}
);
});
});
 Jan 2 at 10:41


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.














  • 1





    Also: mywiki.wooledge.org/WordSplitting

    – ilkkachu
    Jan 2 at 10:47














1












1








1









This question already has an answer here:




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

    4 answers



  • When is double-quoting necessary?

    1 answer




I have the following bash function :



tg() {

  git add -A && git commit -m $1 && git push

}


But it seems not to work :



$ tg "create index for users"

error: pathspec 'index' did not match any file(s) known to git.

error: pathspec 'for' did not match any file(s) known to git.

error: pathspec 'users' did not match any file(s) known to git.


Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



What did I do wrong ? How can I fix this ?






bash quoting







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



  • When is double-quoting necessary?

    1 answer




I have the following bash function :



tg() {

  git add -A && git commit -m $1 && git push

}


But it seems not to work :



$ tg "create index for users"

error: pathspec 'index' did not match any file(s) known to git.

error: pathspec 'for' did not match any file(s) known to git.

error: pathspec 'users' did not match any file(s) known to git.


Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



What did I do wrong ? How can I fix this ?





This question already has an answer here:




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

    4 answers



  • When is double-quoting necessary?

    1 answer







bash quoting




bash quoting






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 2 at 10:35









Rui F Ribeiro

41.4k1481140




41.4k1481140










asked Jan 2 at 9:53









Ewan DelanoyEwan Delanoy

1627




1627




marked as duplicate by 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();
}
);
});
});
 Jan 2 at 10:41


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 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();
}
);
});
});
 Jan 2 at 10:41


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.










  • 1





    Also: mywiki.wooledge.org/WordSplitting

    – ilkkachu
    Jan 2 at 10:47














  • 1





    Also: mywiki.wooledge.org/WordSplitting

    – ilkkachu
    Jan 2 at 10:47








1




1





Also: mywiki.wooledge.org/WordSplitting

– ilkkachu
Jan 2 at 10:47





Also: mywiki.wooledge.org/WordSplitting

– ilkkachu
Jan 2 at 10:47










1 Answer
1






active

oldest

votes


















4














Double quote the expansion $1:



tg() {

  git add -A &&

  git commit -m "$1" &&

  git push

}


By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



Related:




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

  • When is double-quoting necessary?

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






share|improve this answer


























  • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

    – Ewan Delanoy
    Jan 2 at 10:03






  • 2





    @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

    – Kusalananda
    Jan 2 at 10:06













  • Got it, thx. I'll try your solution a few times and accept it if it works.

    – Ewan Delanoy
    Jan 2 at 10:08








  • 1





    @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

    – Sergiy Kolodyazhnyy
    Jan 2 at 10:09








  • 1





    @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

    – Kusalananda
    Jan 2 at 10:13




















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














Double quote the expansion $1:



tg() {

  git add -A &&

  git commit -m "$1" &&

  git push

}


By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



Related:




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

  • When is double-quoting necessary?

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






share|improve this answer


























  • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

    – Ewan Delanoy
    Jan 2 at 10:03






  • 2





    @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

    – Kusalananda
    Jan 2 at 10:06













  • Got it, thx. I'll try your solution a few times and accept it if it works.

    – Ewan Delanoy
    Jan 2 at 10:08








  • 1





    @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

    – Sergiy Kolodyazhnyy
    Jan 2 at 10:09








  • 1





    @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

    – Kusalananda
    Jan 2 at 10:13


















4














Double quote the expansion $1:



tg() {

  git add -A &&

  git commit -m "$1" &&

  git push

}


By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



Related:




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

  • When is double-quoting necessary?

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






share|improve this answer


























  • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

    – Ewan Delanoy
    Jan 2 at 10:03






  • 2





    @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

    – Kusalananda
    Jan 2 at 10:06













  • Got it, thx. I'll try your solution a few times and accept it if it works.

    – Ewan Delanoy
    Jan 2 at 10:08








  • 1





    @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

    – Sergiy Kolodyazhnyy
    Jan 2 at 10:09








  • 1





    @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

    – Kusalananda
    Jan 2 at 10:13
















4












4








4







Double quote the expansion $1:



tg() {

  git add -A &&

  git commit -m "$1" &&

  git push

}


By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



Related:




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

  • When is double-quoting necessary?

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






share|improve this answer















Double quote the expansion $1:



tg() {

  git add -A &&

  git commit -m "$1" &&

  git push

}


By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



Related:




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

  • When is double-quoting necessary?

  • 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 Jan 2 at 10:11

























answered Jan 2 at 9:58









KusalanandaKusalananda

135k17255419




135k17255419













  • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

    – Ewan Delanoy
    Jan 2 at 10:03






  • 2





    @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

    – Kusalananda
    Jan 2 at 10:06













  • Got it, thx. I'll try your solution a few times and accept it if it works.

    – Ewan Delanoy
    Jan 2 at 10:08








  • 1





    @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

    – Sergiy Kolodyazhnyy
    Jan 2 at 10:09








  • 1





    @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

    – Kusalananda
    Jan 2 at 10:13





















  • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

    – Ewan Delanoy
    Jan 2 at 10:03






  • 2





    @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

    – Kusalananda
    Jan 2 at 10:06













  • Got it, thx. I'll try your solution a few times and accept it if it works.

    – Ewan Delanoy
    Jan 2 at 10:08








  • 1





    @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

    – Sergiy Kolodyazhnyy
    Jan 2 at 10:09








  • 1





    @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

    – Kusalananda
    Jan 2 at 10:13



















Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

– Ewan Delanoy
Jan 2 at 10:03





Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?

– Ewan Delanoy
Jan 2 at 10:03




2




2





@EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

– Kusalananda
Jan 2 at 10:06







@EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.

– Kusalananda
Jan 2 at 10:06















Got it, thx. I'll try your solution a few times and accept it if it works.

– Ewan Delanoy
Jan 2 at 10:08







Got it, thx. I'll try your solution a few times and accept it if it works.

– Ewan Delanoy
Jan 2 at 10:08






1




1





@EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

– Sergiy Kolodyazhnyy
Jan 2 at 10:09







@EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.

– Sergiy Kolodyazhnyy
Jan 2 at 10:09






1




1





@SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

– Kusalananda
Jan 2 at 10:13







@SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.

– Kusalananda
Jan 2 at 10:13





-

Popular posts from this blog

Monofisismo

Image
Monofisismo (do grego: monos - "único, singular" e physis - "natureza") é o ponto de vista cristológico que defende que, depois da união do divino e do humano na encarnação histórica, Jesus Cristo, como encarnação do Filho ou Verbo ( Logos ) de Deus, teria apenas uma única "natureza", a divina, e não uma síntese de ambas. O monofisismo é contraposto pelo diofisismo (ou "diafisismo"), que defende que Jesus preservou em si as duas naturezas. Historicamente, o monofisismo se refere primordialmente à posição dos que (especialmente no Egito e, em menor grau, na Síria) rejeitaram as decisões do Concílio de Calcedônia em 451 (o quarto concílio ecumênico). Os membros mais moderados entre eles, porém, defendem a teologia "miafisita", que se tornou a oficial para as Igrejas Ortodoxas Orientais. Muitos ortodoxos orientais, porém, rejeitam essa classificação, mesmo como um termo genérico, mas ele é amplamente utilizado na literatura históri
Read more

Angular Downloading a file using contenturl with Basic Authentication

Image
0 I have a contentUrl when user clicks on that,file should be downloaded. If I try to browse the contentUrl in the browser it asks for Userid and password.I believe this is Basic Authentication.I dont want user to enter UserId and Password so I am passing it Authorization(Please see below code). Url looks some thing like this: http://XXX.XXX.XX.XXX:8080/flowable-rest/service/runtime/tasks/90875/attachments/90555/content let username : string = 'admin'; let pwd : string = 'test'; let headers = new Headers(); headers.set('Accept', 'text/json'); headers.append('Content-Type', 'application/json'); headers.set('Access-Control-Allow-Origin', '*'); headers.set('Access-Control-Allow-Methods','POST, GET, OPTIONS, PUT, DELETE'); head
Read more

Olmecas

Image
Monumento 1, uma das quatro cabeças colossais encontradas em La Venta, com altura aproximada de 3 metros Olmecas é a designação do povo e da civilização que estiveram na origem da antiga cultura pré-colombiana da Mesoamérica e que se desenvolveram nas regiões tropicais do centro-sul do atual México durante o pré-clássico, próximo de onde hoje estão localizados os estados mexicanos de Veracruz e Tabasco, no Istmo de Tehuantepec, numa zona designada área nuclear olmeca. A cultura olmeca floresceu nesta região aproximadamente entre 1500 e 400 a.C., [ 1 ] e crê-se que tenha sido a civilização-mãe de todas as civilizações mesoamericanas que se desenvolveram posteriormente. [ 2 ] No entanto, desconhece-se a sua exacta filiação étnica, ainda que existam numerosas hipóteses colocadas para tentar resolver esta questão. O etnónimo olmeca foi cunhado pelos arqueólogos do século XX, e não devem confundir-se com os muito posteriores olmecas-xicalancas que ocuparam vários locais do México
Read more