Watched this in 2023 and was super helpful. For the task in this video, what I did in my practice was to cast the string pointer (char *) to an unsigned long(which would be the numerical value for the string's starting byte), write that number to the pipe, read the number in the parent, cast it back to a char * and then print the string using %s. This way, I never used strlen because I didn't need to calculate the length of the string. Also, I maintained only one array and didn't have to create another in the parent. It works, is a lot shorter and I also think would execute faster. Thought to share this, but honestly, the unix Processes playlist has taught me a whole lot of things. Thank you!
Watch out, this could cause a segfault since memory is not always shared between processes. I don't recommend passing pointers through pipes unless you are using shared memory
Small error: The capacity of the string buffer should be defined as: #define MAX_LEN 200 and the string array should be declared as: char str[MAX_LEN+1]; // +1 for the null byte terminator! And the null terminator should be placed as: str[strlen(str)] = 0x00; // if the string length == 0, the null byte comes at position 0 (not -1) ! and in the read and write functions you use MAX_LEN instead of 200.
For sure! Using a macro for the max length is better in that situation Here is the reasoning behind my approach: fgets also reads the (end of line character) so you'll always have at least 1 character in the buffer. This line is so that the gets replaced by the NULL terminator. Otherwise NULL terminator is already at strlen(str) (hence why we can even use strlen) so you don't need to set it: str[strlen(str) - 1] = 0; This is also the reason why we don't need to define str to be of MAX_LEN + 1 length. Also, fgets always adds a NULL terminator at the end of the string and removes whatever extra characters there are. Although, yes, if you were to read a 200 character string in that case, the last character (at index 198) might be removed because of that. Sometimes I try to keep it simple in favour of ease of understanding even though the code is 100% correct
My solution was to set a fixed number of bytes to be written/read on each end (lets say 100 bytes), and all messages are sent and read in 100 bytes. If needed the writing process can loop through and write as many 100 byte strings as needed and at the end it write a escape sequence string ("STOP"). The reading process loops through reading 100 byte strings until it sees the "STOP". This solution allows for variable length messages and the fixed message width may be adjusted during compilation.
That's a neat solution and very similar to how strings are implemented in C (using the NULL terminator). You could try to replace the "STOP" string with the NULL terminator and always send strlen + 1 characters through the pipe (so, including the NULL terminator)
Highest appreciation for both your course contents and your crisp and straight forward style. I was wondering why don't you just send the address of the first character through the pipe (write(fd[1], &str, sizeof(char *))? Being the string already 0\ terminated this should be enough to resume the complete information in the parent process and would not require to send the length of bytes, don't you think? Thank You for your brilliant work again and to keep it up at this excellent level.
The issue with that approach would be that if you modify one of the strings, the changes are applied to the string in the other process (which might not be intended) That is if it would in the first place. Modern operating systems don't even allow (by default) processes to access and overwrite memory owned by other processes.
heyy, I've just found a small issue, that we better don't use strlen() function for one int multiple times (you did it in child process), cause if we would have big data it could make our program work slower. instead of it, we could initialize int n after fgets() function, then assign value of n to strlen(str). thus, instead of using strlen() function to find a position of '\0', we could directly use type str[n] = '\0'. please confirm if you are agree with this suggestion. watching your videos for three days and already like it:) that's the good stuff, man!
Yea that's a good suggestion. Although, I am not sure if this is already taken care of by a compiler optimization. Maybe that's something you can take a look at ;)
There are many ways to do this. If you want a sort of event handler system between the two processes you could simply create a new thread (not process) on the listening side and call functions based on what you receive. On the sending side you would send events from time to time through that pipe so no need for an extra thread.
Hi! Awesome video! Thank you so much for that! But, I'll have operating systems exam next week; I must complete the last part of my project: so, I'd like to ask you: what is the code to write numbers (so, INT) in the pipe?! I've tried to do the casting (from int to string very similar to your example), but at the end of the program, I just can see a bytes stream printed on my screen; Please, could you help me?! Thaaaanks! :)
An int usually has 4 bytes, so you'd just need to use write like so: write(fd[1], &x, sizeof(int)); And read from a pipe like so: read(fd[0], &y, sizeof(int));
Hi, man! :) I've already delivered my project, right today; I changed its layout a little bit. However, thaaank you SO MUUUCH for your great videos!! :) you've just got another follower!! :)
what if we just read sizeof(char) * 200 since we know we can only get 200 characters from the fgets? Is it just a bit less efficient or does it not work at all? And also does every write (on the pipe) wait for the coresponding read (on the pipe) to take place and then the code continues? Cause otherwise how do we know that the second write (on the pipe) won't undo the first write (on the pipe)?
If you read sizeof(char) * 200 you'll have to write exactly that amount. And that's not necessarily more efficient. Also, yes, the read calls wait for there to be something in the pipe's buffer (someone to write into it) AND also, the write calls wait for there to be enough space in the pipe's buffer.
In this instance read 200 would be fine because the child is only writing once and then closing the fd, thus read will just return whatever it was able to find which is the string sent by the child. However if you wanted to do this in a loop the parent will read several strings from a single read I know this comment is old, I'm just replying in case someone else is curious
Thank you for the great content! Can't you read 1 char after another untill you hit the '\0' (or ' ' for that matter)? There is no point of having the terminating '\0' if you send the strlen at the begining.
That's true, you don't need to send the \0, it's just that I didn't want to add the \0 at the receiving end. Seemed odd to let the receiving fix the string which is something you can forget and could cause issues later on
In the read and write functions. Why do soometimes add & before the thing u wanna read or write and sometime u just write the name of variable directly without &
& is just an operator that returns the address of whatever variable you put after it. Whenever you want to tell a function where to read from / where to write to you would need a pointer, that's why I sometimes use the &. Sometimes that & is not needed because the variable itself is already a pointer type and is pointing to the right place already. For example, you could have: int n; read(fd[0], &n, sizeof(int)); // n is just an int so we want the address of that int OR int* n = malloc(sizeof(int)); read(fd[0], n, sizeof(int)); // n is a pointer here so we can just pass it as it is
before watching it I was 99.99% sure that sending string will end up with the same approach as sending arrays - string in C is ... an array ;-) it looks I am getting there (slowly) ;-)
I copied your code as best I could, watched the video twice, but mine doesn't print out the string only "Received: ". Do you have any idea why that might be?
Hello sir I am writing a code such that output of one program is input of another program in the same program. I thought that your code in this code will do the job. But u have used if else statement which means that only one of the if or else statement will execute. Am i right?? Please reply sir
@@CodeVault thank you sir for replying. I completed my code using the code used in this video. Thankyou sir for providing hard to find content of programming on your channel. Love from india❤️❤️🎉🎉.
If both char buffers have the same size, why not writing (in the child) and reading (in the parent) the whole string with the null character instead of writing the lenght first? I mean, even if there is trash value after the null character, printf will not display it. I tested it and it worked.
You're right, that method also works. It just depends on the situation. The size of the string you're passing could be rather large in a few instances and therefore you would have to have a much larger buffer than what you're usually sending. This could waste a lot of processing power for just sending the "trash" bits
so if we use successive write functions to fd.. for latter write functions, doesn't it overwrite the previously written data (from earlier write function) ? if no, then does the fd have a position pointer, which retains the position of the cursor ?
@@CodeVault ohhhhh okay okay, so that means as long as I keep the fd open, it will keep on filling up the buffer. And as soon as i finish- the program will empty the buffer into the file.. have i comprehended correctly ?
Whenever you read from that buffer, the amount of bytes read are being removed from the buffer. If you close the fds while leaving stuff in the buffer there it's going to also empty out.
I likes how the code is so structured and clean . awesome content thanks a lot
Great stuff and hard-to-find content, thanks!
you're doing a great job
Hey man, thanks for the support! :D
Watched this in 2023 and was super helpful. For the task in this video, what I did in my practice was to cast the string pointer (char *) to an unsigned long(which would be the numerical value for the string's starting byte), write that number to the pipe, read the number in the parent, cast it back to a char * and then print the string using %s. This way, I never used strlen because I didn't need to calculate the length of the string. Also, I maintained only one array and didn't have to create another in the parent. It works, is a lot shorter and I also think would execute faster. Thought to share this, but honestly, the unix Processes playlist has taught me a whole lot of things. Thank you!
Watch out, this could cause a segfault since memory is not always shared between processes. I don't recommend passing pointers through pipes unless you are using shared memory
Excellent man...Thanks for this video...
Great video thanks man , you''re AWESOME :)
Small error:
The capacity of the string buffer should be defined as:
#define MAX_LEN 200
and the string array should be declared as:
char str[MAX_LEN+1]; // +1 for the null byte terminator!
And the null terminator should be placed as:
str[strlen(str)] = 0x00; // if the string length == 0, the null byte comes at position 0 (not -1) !
and in the read and write functions you use MAX_LEN instead of 200.
For sure! Using a macro for the max length is better in that situation
Here is the reasoning behind my approach:
fgets also reads the
(end of line character) so you'll always have at least 1 character in the buffer.
This line is so that the
gets replaced by the NULL terminator. Otherwise NULL terminator is already at strlen(str) (hence why we can even use strlen) so you don't need to set it:
str[strlen(str) - 1] = 0;
This is also the reason why we don't need to define str to be of MAX_LEN + 1 length. Also, fgets always adds a NULL terminator at the end of the string and removes whatever extra characters there are.
Although, yes, if you were to read a 200 character string in that case, the last character (at index 198) might be removed because of that. Sometimes I try to keep it simple in favour of ease of understanding even though the code is 100% correct
My solution was to set a fixed number of bytes to be written/read on each end (lets say 100 bytes), and all messages are sent and read in 100 bytes. If needed the writing process can loop through and write as many 100 byte strings as needed and at the end it write a escape sequence string ("STOP"). The reading process loops through reading 100 byte strings until it sees the "STOP". This solution allows for variable length messages and the fixed message width may be adjusted during compilation.
That's a neat solution and very similar to how strings are implemented in C (using the NULL terminator). You could try to replace the "STOP" string with the NULL terminator and always send strlen + 1 characters through the pipe (so, including the NULL terminator)
This is AWESOME!!!!!!!!!
Thank You ! =)
Highest appreciation for both your course contents and your crisp and straight forward style. I was wondering why don't you just send the address of the first character through the pipe (write(fd[1], &str, sizeof(char *))? Being the string already 0\ terminated this should be enough to resume the complete information in the parent process and would not require to send the length of bytes, don't you think? Thank You for your brilliant work again and to keep it up at this excellent level.
The issue with that approach would be that if you modify one of the strings, the changes are applied to the string in the other process (which might not be intended)
That is if it would in the first place. Modern operating systems don't even allow (by default) processes to access and overwrite memory owned by other processes.
heyy, I've just found a small issue, that we better don't use strlen() function for one int multiple times (you did it in child process), cause if we would have big data it could make our program work slower. instead of it, we could initialize int n after fgets() function, then assign value of n to strlen(str). thus, instead of using strlen() function to find a position of '\0', we could directly use type str[n] = '\0'. please confirm if you are agree with this suggestion. watching your videos for three days and already like it:) that's the good stuff, man!
Yea that's a good suggestion. Although, I am not sure if this is already taken care of by a compiler optimization. Maybe that's something you can take a look at ;)
Great stuff! Just a question how you would do if we want to continuously write and read between child and parent
There are many ways to do this. If you want a sort of event handler system between the two processes you could simply create a new thread (not process) on the listening side and call functions based on what you receive. On the sending side you would send events from time to time through that pipe so no need for an extra thread.
Hi! Awesome video! Thank you so much for that! But, I'll have operating systems exam next week; I must complete the last part of my project: so, I'd like to ask you: what is the code to write numbers (so, INT) in the pipe?! I've tried to do the casting (from int to string very similar to your example), but at the end of the program, I just can see a bytes stream printed on my screen; Please, could you help me?! Thaaaanks! :)
An int usually has 4 bytes, so you'd just need to use write like so:
write(fd[1], &x, sizeof(int));
And read from a pipe like so:
read(fd[0], &y, sizeof(int));
Hi, man! :) I've already delivered my project, right today; I changed its layout a little bit. However, thaaank you SO MUUUCH for your great videos!! :) you've just got another follower!! :)
How would you go about sending a struct over a pipe? Lets say that the struct contains a variable lenght strings and arrays.
Actually I will make a video on this topic... possibly this week. Seems like something I omitted
what if we just read sizeof(char) * 200 since we know we can only get 200 characters from the fgets?
Is it just a bit less efficient or does it not work at all?
And also does every write (on the pipe) wait for the coresponding read (on the pipe) to take place and then the code continues?
Cause otherwise how do we know that the second write (on the pipe) won't undo the first write (on the pipe)?
If you read sizeof(char) * 200 you'll have to write exactly that amount. And that's not necessarily more efficient.
Also, yes, the read calls wait for there to be something in the pipe's buffer (someone to write into it) AND also, the write calls wait for there to be enough space in the pipe's buffer.
@@CodeVault Alright, thanks!
In this instance read 200 would be fine because the child is only writing once and then closing the fd, thus read will just return whatever it was able to find which is the string sent by the child. However if you wanted to do this in a loop the parent will read several strings from a single read
I know this comment is old, I'm just replying in case someone else is curious
Thank you for the great content!
Can't you read 1 char after another untill you hit the '\0' (or '
' for that matter)? There is no point of having the terminating '\0' if you send the strlen at the begining.
That's true, you don't need to send the \0, it's just that I didn't want to add the \0 at the receiving end. Seemed odd to let the receiving fix the string which is something you can forget and could cause issues later on
In the read and write functions.
Why do soometimes add & before the thing u wanna read or write and sometime u just write the name of variable directly without &
& is just an operator that returns the address of whatever variable you put after it. Whenever you want to tell a function where to read from / where to write to you would need a pointer, that's why I sometimes use the &.
Sometimes that & is not needed because the variable itself is already a pointer type and is pointing to the right place already.
For example, you could have:
int n;
read(fd[0], &n, sizeof(int)); // n is just an int so we want the address of that int
OR
int* n = malloc(sizeof(int));
read(fd[0], n, sizeof(int)); // n is a pointer here so we can just pass it as it is
before watching it I was 99.99% sure that sending string will end up with the same approach as sending arrays - string in C is ... an array ;-)
it looks I am getting there (slowly) ;-)
I copied your code as best I could, watched the video twice, but mine doesn't print out the string only "Received: ". Do you have any idea why that might be?
I figured it out.
Hello sir
I am writing a code such that output of one program is input of another program in the same program.
I thought that your code in this code will do the job.
But u have used if else statement which means that only one of the if or else statement will execute. Am i right??
Please reply sir
Yes, if you only have one process... That will happen
@@CodeVault thank you sir for replying.
I completed my code using the code used in this video.
Thankyou sir for providing hard to find content of programming on your channel.
Love from india❤️❤️🎉🎉.
If both char buffers have the same size, why not writing (in the child) and reading (in the parent) the whole string with the null character instead of writing the lenght first? I mean, even if there is trash value after the null character, printf will not display it. I tested it and it worked.
You're right, that method also works. It just depends on the situation. The size of the string you're passing could be rather large in a few instances and therefore you would have to have a much larger buffer than what you're usually sending. This could waste a lot of processing power for just sending the "trash" bits
@@CodeVault Thanks for replying! It is truly commendable from your part to reply every comment. Also, I love your videos and the way you teach stuff.
so if we use successive write functions to fd.. for latter write functions, doesn't it overwrite the previously written data (from earlier write function) ?
if no, then does the fd have a position pointer, which retains the position of the cursor ?
The pipes have a buffer. When you write to them, it fills up that buffer, when you read from them it empties it out
@@CodeVault ohhhhh okay okay, so that means as long as I keep the fd open, it will keep on filling up the buffer. And as soon as i finish- the program will empty the buffer into the file.. have i comprehended correctly ?
Whenever you read from that buffer, the amount of bytes read are being removed from the buffer. If you close the fds while leaving stuff in the buffer there it's going to also empty out.
@@CodeVault okay, thank you so much for your help, I really appreciate it, thank you !