problem with loading tcshrc
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I have ubuntu 16.04 installed on my local pc and I'm trying to make my work environment as similar to the way it is configured at my job
to achieve that I wanted to use the same tcshrc file (yes, we use tcsh, not sure why...)
anyway, when I try to open a tcsh terminal (or to source ~/.tcshrc for the matter) I'm getting an error:
set: Variable name must begin with a letter.
trying to isolate the cause I found out that the next lines are enough to cause it
#!/bin/tcsh
echo 0
set history = 2000 # this line is not the cause, verified by echoing
echo 1
set savehist = (2000 merge)
echo 2
output:
0
1
set: Variable name must begin with a letter.
when i try to run set savehist = (2000 merge) as a regular shell command the terminal doesn't show any error.
ofcourse that at my job the tcshrc is working fine. in both I have tcsh 6.18.01 installed
any help is welcome
thanks
tcsh
add a comment |Â
up vote
2
down vote
favorite
I have ubuntu 16.04 installed on my local pc and I'm trying to make my work environment as similar to the way it is configured at my job
to achieve that I wanted to use the same tcshrc file (yes, we use tcsh, not sure why...)
anyway, when I try to open a tcsh terminal (or to source ~/.tcshrc for the matter) I'm getting an error:
set: Variable name must begin with a letter.
trying to isolate the cause I found out that the next lines are enough to cause it
#!/bin/tcsh
echo 0
set history = 2000 # this line is not the cause, verified by echoing
echo 1
set savehist = (2000 merge)
echo 2
output:
0
1
set: Variable name must begin with a letter.
when i try to run set savehist = (2000 merge) as a regular shell command the terminal doesn't show any error.
ofcourse that at my job the tcshrc is working fine. in both I have tcsh 6.18.01 installed
any help is welcome
thanks
tcsh
1
As much as I usedtcsh
on Mac OS X back in the good old days, 10.0-10.3 ... it sucks as a shell. For interactive use it is sort of OK, except, precisely, when you have a nice script to source ... it is a poor excuse for a shell. I am sure it is a corporate fallacy^H^H^H^H^H^H^Hpolicy. "corporate policies", when you hear that, you know it is brain dead and the "policy" is just some excuse for folly...
â thecarpy
Nov 21 '17 at 18:40
@thecarpy truely I don't even know what's so bad with it anyway. I'm not using the "scripting environment" of it so maybe that's why I don't really care which shell I'm using.
â user2717954
Nov 21 '17 at 19:20
Google is your friend, why trust me...
â thecarpy
Nov 21 '17 at 19:21
@user2717954, have you copied the working file from the working system? What happens if you type the file or the relevant rows again from scratch? (Take a backup of the file first, so that you can examine it later.)
â ilkkachu
Nov 21 '17 at 20:44
@ilkkachu well it seems that you are right (atleast the failing line is not failing anymore..) is there any way to "sanitize" my copied file? copying it by hand it somewhat boring and unproductive..
â user2717954
Nov 21 '17 at 20:55
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I have ubuntu 16.04 installed on my local pc and I'm trying to make my work environment as similar to the way it is configured at my job
to achieve that I wanted to use the same tcshrc file (yes, we use tcsh, not sure why...)
anyway, when I try to open a tcsh terminal (or to source ~/.tcshrc for the matter) I'm getting an error:
set: Variable name must begin with a letter.
trying to isolate the cause I found out that the next lines are enough to cause it
#!/bin/tcsh
echo 0
set history = 2000 # this line is not the cause, verified by echoing
echo 1
set savehist = (2000 merge)
echo 2
output:
0
1
set: Variable name must begin with a letter.
when i try to run set savehist = (2000 merge) as a regular shell command the terminal doesn't show any error.
ofcourse that at my job the tcshrc is working fine. in both I have tcsh 6.18.01 installed
any help is welcome
thanks
tcsh
I have ubuntu 16.04 installed on my local pc and I'm trying to make my work environment as similar to the way it is configured at my job
to achieve that I wanted to use the same tcshrc file (yes, we use tcsh, not sure why...)
anyway, when I try to open a tcsh terminal (or to source ~/.tcshrc for the matter) I'm getting an error:
set: Variable name must begin with a letter.
trying to isolate the cause I found out that the next lines are enough to cause it
#!/bin/tcsh
echo 0
set history = 2000 # this line is not the cause, verified by echoing
echo 1
set savehist = (2000 merge)
echo 2
output:
0
1
set: Variable name must begin with a letter.
when i try to run set savehist = (2000 merge) as a regular shell command the terminal doesn't show any error.
ofcourse that at my job the tcshrc is working fine. in both I have tcsh 6.18.01 installed
any help is welcome
thanks
tcsh
asked Oct 21 '17 at 20:12
user2717954
135
135
1
As much as I usedtcsh
on Mac OS X back in the good old days, 10.0-10.3 ... it sucks as a shell. For interactive use it is sort of OK, except, precisely, when you have a nice script to source ... it is a poor excuse for a shell. I am sure it is a corporate fallacy^H^H^H^H^H^H^Hpolicy. "corporate policies", when you hear that, you know it is brain dead and the "policy" is just some excuse for folly...
â thecarpy
Nov 21 '17 at 18:40
@thecarpy truely I don't even know what's so bad with it anyway. I'm not using the "scripting environment" of it so maybe that's why I don't really care which shell I'm using.
â user2717954
Nov 21 '17 at 19:20
Google is your friend, why trust me...
â thecarpy
Nov 21 '17 at 19:21
@user2717954, have you copied the working file from the working system? What happens if you type the file or the relevant rows again from scratch? (Take a backup of the file first, so that you can examine it later.)
â ilkkachu
Nov 21 '17 at 20:44
@ilkkachu well it seems that you are right (atleast the failing line is not failing anymore..) is there any way to "sanitize" my copied file? copying it by hand it somewhat boring and unproductive..
â user2717954
Nov 21 '17 at 20:55
add a comment |Â
1
As much as I usedtcsh
on Mac OS X back in the good old days, 10.0-10.3 ... it sucks as a shell. For interactive use it is sort of OK, except, precisely, when you have a nice script to source ... it is a poor excuse for a shell. I am sure it is a corporate fallacy^H^H^H^H^H^H^Hpolicy. "corporate policies", when you hear that, you know it is brain dead and the "policy" is just some excuse for folly...
â thecarpy
Nov 21 '17 at 18:40
@thecarpy truely I don't even know what's so bad with it anyway. I'm not using the "scripting environment" of it so maybe that's why I don't really care which shell I'm using.
â user2717954
Nov 21 '17 at 19:20
Google is your friend, why trust me...
â thecarpy
Nov 21 '17 at 19:21
@user2717954, have you copied the working file from the working system? What happens if you type the file or the relevant rows again from scratch? (Take a backup of the file first, so that you can examine it later.)
â ilkkachu
Nov 21 '17 at 20:44
@ilkkachu well it seems that you are right (atleast the failing line is not failing anymore..) is there any way to "sanitize" my copied file? copying it by hand it somewhat boring and unproductive..
â user2717954
Nov 21 '17 at 20:55
1
1
As much as I used
tcsh
on Mac OS X back in the good old days, 10.0-10.3 ... it sucks as a shell. For interactive use it is sort of OK, except, precisely, when you have a nice script to source ... it is a poor excuse for a shell. I am sure it is a corporate fallacy^H^H^H^H^H^H^Hpolicy. "corporate policies", when you hear that, you know it is brain dead and the "policy" is just some excuse for folly...â thecarpy
Nov 21 '17 at 18:40
As much as I used
tcsh
on Mac OS X back in the good old days, 10.0-10.3 ... it sucks as a shell. For interactive use it is sort of OK, except, precisely, when you have a nice script to source ... it is a poor excuse for a shell. I am sure it is a corporate fallacy^H^H^H^H^H^H^Hpolicy. "corporate policies", when you hear that, you know it is brain dead and the "policy" is just some excuse for folly...â thecarpy
Nov 21 '17 at 18:40
@thecarpy truely I don't even know what's so bad with it anyway. I'm not using the "scripting environment" of it so maybe that's why I don't really care which shell I'm using.
â user2717954
Nov 21 '17 at 19:20
@thecarpy truely I don't even know what's so bad with it anyway. I'm not using the "scripting environment" of it so maybe that's why I don't really care which shell I'm using.
â user2717954
Nov 21 '17 at 19:20
Google is your friend, why trust me...
â thecarpy
Nov 21 '17 at 19:21
Google is your friend, why trust me...
â thecarpy
Nov 21 '17 at 19:21
@user2717954, have you copied the working file from the working system? What happens if you type the file or the relevant rows again from scratch? (Take a backup of the file first, so that you can examine it later.)
â ilkkachu
Nov 21 '17 at 20:44
@user2717954, have you copied the working file from the working system? What happens if you type the file or the relevant rows again from scratch? (Take a backup of the file first, so that you can examine it later.)
â ilkkachu
Nov 21 '17 at 20:44
@ilkkachu well it seems that you are right (atleast the failing line is not failing anymore..) is there any way to "sanitize" my copied file? copying it by hand it somewhat boring and unproductive..
â user2717954
Nov 21 '17 at 20:55
@ilkkachu well it seems that you are right (atleast the failing line is not failing anymore..) is there any way to "sanitize" my copied file? copying it by hand it somewhat boring and unproductive..
â user2717954
Nov 21 '17 at 20:55
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
5
down vote
accepted
One possible reason: you actually have an invalid character in there, accidentally added when creating the file. It would have to be something that's normally not (very) visible, for example, a non-breaking space or some such.
$ cat test.csh
set foo = bar
$ tcsh test.csh
set: Variable name must begin with a letter.
$ od -c test.csh
0000000 s e t 342 201 240 f o o = b a r
0000020 n
0000021
That was a zero-width word joiner, it actually doesn't print on my system.
Something like that od
above should show you what there actually is.
The easiest way to get rid of characters like that is probably to just find the offending line(s) from the error messages, and re-type them from scratch. (or debugging prints instead of error messages, since tcsh
doesn't seem to give line numbers in them. oh well.)
But if you want to, you could pipe the whole file through something like tr -d '200-377'
, which would remove all bytes with the high bit set. (That is, assuming the file is UTF-8 encoded, and that tr
works as it seems to work on my system, on bytes, not actual characters, and that there aren't any other non-ASCII characters you'd like to keep. Make backups.)
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
add a comment |Â
up vote
0
down vote
Have in the.tcshrc file simply:
set history=2000
set savehist=(2000 merge)
Note: there are no spaces infront or after the = sign.
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
One possible reason: you actually have an invalid character in there, accidentally added when creating the file. It would have to be something that's normally not (very) visible, for example, a non-breaking space or some such.
$ cat test.csh
set foo = bar
$ tcsh test.csh
set: Variable name must begin with a letter.
$ od -c test.csh
0000000 s e t 342 201 240 f o o = b a r
0000020 n
0000021
That was a zero-width word joiner, it actually doesn't print on my system.
Something like that od
above should show you what there actually is.
The easiest way to get rid of characters like that is probably to just find the offending line(s) from the error messages, and re-type them from scratch. (or debugging prints instead of error messages, since tcsh
doesn't seem to give line numbers in them. oh well.)
But if you want to, you could pipe the whole file through something like tr -d '200-377'
, which would remove all bytes with the high bit set. (That is, assuming the file is UTF-8 encoded, and that tr
works as it seems to work on my system, on bytes, not actual characters, and that there aren't any other non-ASCII characters you'd like to keep. Make backups.)
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
add a comment |Â
up vote
5
down vote
accepted
One possible reason: you actually have an invalid character in there, accidentally added when creating the file. It would have to be something that's normally not (very) visible, for example, a non-breaking space or some such.
$ cat test.csh
set foo = bar
$ tcsh test.csh
set: Variable name must begin with a letter.
$ od -c test.csh
0000000 s e t 342 201 240 f o o = b a r
0000020 n
0000021
That was a zero-width word joiner, it actually doesn't print on my system.
Something like that od
above should show you what there actually is.
The easiest way to get rid of characters like that is probably to just find the offending line(s) from the error messages, and re-type them from scratch. (or debugging prints instead of error messages, since tcsh
doesn't seem to give line numbers in them. oh well.)
But if you want to, you could pipe the whole file through something like tr -d '200-377'
, which would remove all bytes with the high bit set. (That is, assuming the file is UTF-8 encoded, and that tr
works as it seems to work on my system, on bytes, not actual characters, and that there aren't any other non-ASCII characters you'd like to keep. Make backups.)
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
add a comment |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
One possible reason: you actually have an invalid character in there, accidentally added when creating the file. It would have to be something that's normally not (very) visible, for example, a non-breaking space or some such.
$ cat test.csh
set foo = bar
$ tcsh test.csh
set: Variable name must begin with a letter.
$ od -c test.csh
0000000 s e t 342 201 240 f o o = b a r
0000020 n
0000021
That was a zero-width word joiner, it actually doesn't print on my system.
Something like that od
above should show you what there actually is.
The easiest way to get rid of characters like that is probably to just find the offending line(s) from the error messages, and re-type them from scratch. (or debugging prints instead of error messages, since tcsh
doesn't seem to give line numbers in them. oh well.)
But if you want to, you could pipe the whole file through something like tr -d '200-377'
, which would remove all bytes with the high bit set. (That is, assuming the file is UTF-8 encoded, and that tr
works as it seems to work on my system, on bytes, not actual characters, and that there aren't any other non-ASCII characters you'd like to keep. Make backups.)
One possible reason: you actually have an invalid character in there, accidentally added when creating the file. It would have to be something that's normally not (very) visible, for example, a non-breaking space or some such.
$ cat test.csh
set foo = bar
$ tcsh test.csh
set: Variable name must begin with a letter.
$ od -c test.csh
0000000 s e t 342 201 240 f o o = b a r
0000020 n
0000021
That was a zero-width word joiner, it actually doesn't print on my system.
Something like that od
above should show you what there actually is.
The easiest way to get rid of characters like that is probably to just find the offending line(s) from the error messages, and re-type them from scratch. (or debugging prints instead of error messages, since tcsh
doesn't seem to give line numbers in them. oh well.)
But if you want to, you could pipe the whole file through something like tr -d '200-377'
, which would remove all bytes with the high bit set. (That is, assuming the file is UTF-8 encoded, and that tr
works as it seems to work on my system, on bytes, not actual characters, and that there aren't any other non-ASCII characters you'd like to keep. Make backups.)
edited Nov 21 '17 at 21:09
answered Nov 21 '17 at 20:58
ilkkachu
50.8k678140
50.8k678140
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
add a comment |Â
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
you are correct, I'll assign the bounty in 21 hours
â user2717954
Nov 21 '17 at 21:03
add a comment |Â
up vote
0
down vote
Have in the.tcshrc file simply:
set history=2000
set savehist=(2000 merge)
Note: there are no spaces infront or after the = sign.
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
add a comment |Â
up vote
0
down vote
Have in the.tcshrc file simply:
set history=2000
set savehist=(2000 merge)
Note: there are no spaces infront or after the = sign.
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Have in the.tcshrc file simply:
set history=2000
set savehist=(2000 merge)
Note: there are no spaces infront or after the = sign.
Have in the.tcshrc file simply:
set history=2000
set savehist=(2000 merge)
Note: there are no spaces infront or after the = sign.
answered Nov 21 '17 at 18:22
tukan
1343
1343
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
add a comment |Â
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
I'm getting the same output [0 1 set: Variable name must begin with a letter.] and the set history = 2000 (with spaces) is not causing me any errors so I'm sorry but this answer is not working for me
â user2717954
Nov 21 '17 at 19:16
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
Well the point was to create the file from scratch. Did you do that?
â tukan
Nov 22 '17 at 8:17
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f399610%2fproblem-with-loading-tcshrc%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
As much as I used
tcsh
on Mac OS X back in the good old days, 10.0-10.3 ... it sucks as a shell. For interactive use it is sort of OK, except, precisely, when you have a nice script to source ... it is a poor excuse for a shell. I am sure it is a corporate fallacy^H^H^H^H^H^H^Hpolicy. "corporate policies", when you hear that, you know it is brain dead and the "policy" is just some excuse for folly...â thecarpy
Nov 21 '17 at 18:40
@thecarpy truely I don't even know what's so bad with it anyway. I'm not using the "scripting environment" of it so maybe that's why I don't really care which shell I'm using.
â user2717954
Nov 21 '17 at 19:20
Google is your friend, why trust me...
â thecarpy
Nov 21 '17 at 19:21
@user2717954, have you copied the working file from the working system? What happens if you type the file or the relevant rows again from scratch? (Take a backup of the file first, so that you can examine it later.)
â ilkkachu
Nov 21 '17 at 20:44
@ilkkachu well it seems that you are right (atleast the failing line is not failing anymore..) is there any way to "sanitize" my copied file? copying it by hand it somewhat boring and unproductive..
â user2717954
Nov 21 '17 at 20:55