ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The program does in fact work, the problem is in getting the input line to go through without being messed with by bash.
If that's correct, then it's easy to investigate. Have the assembly language program print out the arguments passed to it. Then you know what it expects and what it's getting instead.
At least the string is getting through now, but I wish I could get rid of the, "dumps".
It sounds like it was always getting through, but the NAddr program had (and still has) some bugs. I think the rest of the script is just a distraction. You should focus on testing NAddr by itself.
Code:
# run these and check that the output is what you expect
./NAddr 'a-string'
./NAddr 'a string with spaces'
./NAddr '<an-angle-bracket-enclosed-string>'
./NAddr 'a string with space <and angle brackets>'
# etc etc
It sounds like it was always getting through, but the NAddr program had (and still has) some bugs.
Not allways. The redirection problem was apparently just the top layer.
Quote:
Originally Posted by ntubski
I think the rest of the script is just a distraction. You should focus on testing NAddr by itself.
Perhaps, though as you and the others have pointed out, it was up for a little fine tuning.
Quote:
Originally Posted by ntubski
Code:
# run these and check that the output is what you expect
./NAddr 'a-string'
./NAddr 'a string with spaces'
./NAddr '<an-angle-bracket-enclosed-string>'
./NAddr 'a string with space <and angle brackets>'
# etc etc
Ok, I'll get on it. Gotta go get some groceries right now though. I'll try to get back to it in a few hours. Thanks everyone for helping to clarify the situation.
Not allways. The redirection problem was apparently just the top layer.
Bash doesn't interpret redirection characters inside variables, there have been lots of threads started by people who expected it to. So my guess is, you just misinterpreted the error message. Since you declined to share the error message, we can't say for sure...
Bash doesn't interpret redirection characters inside variables, there have been lots of threads started by people who expected it to. So my guess is, you just misinterpreted the error message. Since you declined to share the error message, we can't say for sure...
Really? There have only been two. Hows, "Error near unexpected newline", grab ya? The other you've allready seen.
Doesn't sound like a redirection problem. Is that the whole message? Usually there is prefix indicating which program and line number it's from, eg: "bash: line 42: Error near unexpected newline". Though perhaps the message is from msmtp, indicating that NAddr added a newline to its output (and therefore the $To variable).
Doesn't sound like a redirection problem. Is that the whole message? Usually there is prefix indicating which program and line number it's from, eg: "bash: line 42: Error near unexpected newline". Though perhaps the message is from msmtp, indicating that NAddr added a newline to its output (and therefore the $To variable).
Nope, just, "Error near unexpected newline", and nothing else.
NAddr only outputs a newline after the string is printed out. It wasn't printed when these errors occured.
Possibly, but I was trying to do a solution that would _allways_ work, regardless of what mailer I might wind up playing with, and whatever characteristics they might have in their output.
So, is that why you wrote 60 lines of code in assembly, whose sole purpose is to print the argument that starts with '<' and which segfaults whenever called with
a/ no argument
b/ arguments none of which starts with '<'
c/ arguments one of which starts with '<' but doesn't contain the closing '>'
d/ arguments that start with '<' but is longer than 127 bytes
So, is that why you wrote 60 lines of code in assembly,
Actually, its closer to 30 lines of code, not counting labels, comments, and linefeeds. I also wrote it as an exercise in dealling with cli parameters in future programming. Whats your problem with assembly?
Quote:
Originally Posted by millgates
starts with '<' and which segfaults whenever called with
a/ no argument
b/ arguments none of which starts with '<'
c/ arguments one of which starts with '<' but doesn't contain the closing '>'
d/ arguments that start with '<' but is longer than 127 bytes
Well, it's apparently down to that one error, which
is a deal better than anyone can do in C. C is a language in which a single typo generates 60,000 pages of arcane, indecipherable, error messages.
I also wrote it as an exercise in dealling with cli parameters in future programming. Whats your problem with assembly?
OK, if you do it for sake of practice, it's OK. There's no problem with assembly, it's just that it's really not the best tool for this job. Neither is C, actually.
This is a simple string manipulation which is exactly what the command line utilities like grep, sed, and awk were designed for. This one is even simple enough to be done directly in bash with builtin string manipulations, avoiding the need to execute external programs. The problem with your code is that it expects very specific input and crashes when it gets anything else. You loop over command line arguments but you discard argc and don't check whether you have reached the end of argv. You loop over the string until you find '>', but you don't check for a null char terminating the string.
Quote:
Originally Posted by billvance
Well, it's apparently down to that one error, which is a deal better than anyone can do in C. C is a language in which a single typo generates 60,000 pages of arcane, indecipherable, error messages.
If you're referring to the gcc compiler messages then yes, they have a tendency to be slightly cryptic sometimes (especially to people new to C), but I don't think debugging C code is more difficult than debugging assembly, especially when it's somebody else's code.
Quote:
Originally Posted by billvance
Now that's interesting. How does that work?
Those are bash builtin string manipulations. ${varname#expr} removes expr form the beginning of the string ${varname##expr} does the same thing but is greedy.
Analogically, ${varname%expr} removes expr from the end of the string ${varname%%expr} is the greedy variant.
OK, if you do it for sake of practice, it's OK. There's no problem with assembly, it's just that it's really not the best tool for this job. Neither is C, actually.
This is a simple string manipulation which is exactly what the command line utilities like grep, sed, and awk were designed for. This one is even simple enough to be done directly in bash with builtin string manipulations, avoiding the need to execute external programs. The problem with your code is that it expects very specific input and crashes when it gets anything else. You loop over command line arguments but you discard argc and don't check whether you have reached the end of argv. You loop over the string until you find '>', but you don't check for a null char terminating the string.
In this particular instance, I've only been interested in getting one exact kind of parameter.
Once it's been found, there's no point in sticking around. That being said, NAddr is allready several versions along from where it was. It still needs work, but no longer seg faults.
Quote:
Originally Posted by millgates
If you're referring to the gcc compiler messages then yes, they have a tendency to be slightly cryptic sometimes (especially to people new to C), but I don't think debugging C code is more difficult than debugging assembly, especially when it's somebody else's code.
In my case, C represents a long term, many versions, on many machines, nightmare, complete with many iterations of the quest for the non-existant dependencies. I refuse to go beyond, ./configure && make && make install. C stands for Cuneiform. I'll program in _sanscrit_ before I program in C.
Quote:
Originally Posted by millgates
Those are bash builtin string manipulations. ${varname#expr} removes expr form the beginning of the string ${varname##expr} does the same thing but is greedy.
Analogically, ${varname%expr} removes expr from the end of the string ${varname%%expr} is the greedy variant.
GetParam:
pop ecx ; $2, now we can go to work
mov esi,ecx ; put string starting addr in esi
; (source index)
mov edi,storage ; put output addr in edi, (destination
; index)
cld ; clr direction flag for incrementing
lodsb ; mov contents of esi (source index) addr
; to eax (accumulator) and increment esi
stosb ; Put char in addr pointed to by edi,
; (destination index) i.e. "storage" and
; increment addr in edi
cmp eax,60 ; is it a, "<", enclosure char
jne GetParam ; if not, get next cli parameter
Bill
popping ecx repeatedly inside a loop w/o a corresponding push is bound to goof up your stack, i think
OK, if you do it for sake of practice, it's OK. There's no problem with assembly, it's just that it's really not the best tool for this job. Neither is C, actually.
This is a simple string manipulation which is exactly what the command line utilities like grep, sed, and awk were designed for. This one is even simple enough to be done directly in bash with builtin string manipulations, avoiding the need to execute external programs. The problem with your code is that it expects very specific input and crashes when it gets anything else. You loop over command line arguments but you discard argc and don't check whether you have reached the end of argv. You loop over the string until you find '>', but you don't check for a null char terminating the string.
If you're referring to the gcc compiler messages then yes, they have a tendency to be slightly cryptic sometimes (especially to people new to C), but I don't think debugging C code is more difficult than debugging assembly, especially when it's somebody else's code.
Those are bash builtin string manipulations. ${varname#expr} removes expr form the beginning of the string ${varname##expr} does the same thing but is greedy.
Analogically, ${varname%expr} removes expr from the end of the string ${varname%%expr} is the greedy variant.
Thanks, Millgates, That really does the trick. Thanks, as well to everyone who has helped to get NAddr into more workable shape. I'll keep working on it, but for now, I'll declare it, tentatively at least, solved. Thanks again.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
