• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root terminal commands....

Yes, you're on the right track. Where are you testing, though? Are you using Linux? I'm sure id -u does what you want, but it doesn't work in Android, or at least not with the version of busybox that I have. I just displays the same thing as id, without any arguments. Did you try the other bashrc that I uploaded? I kinda hacked it together, but it worked for me, and it uses id instead of whoami.

As for PS1, yeah, run that from adb shell. It should change your prompt into something slightly more readable (just the $ for normal user and # for root). What is the shell you're first using after you run adb shell, in the first place? I would think it'd still be sh, not bash.

EDIT: If id -u did what you're saying (displays 0 for root or some other number for other users), this is what I'd do:

Code:
if [ `id -u` == 0 ];then
    echo "root"
else
    echo "some other user"
fi
My guess though, is that it would still have a string that looks like this:

uid=0(root) or uid=0

or something like that. I'll be in front of a real linux box tomorrow to test that. Until then, it doesn't work quite right in Android, hence my silly little hack. It does seem to work, though. Try it out (the bashrc I posted a few posts up) and let me know if it works. If it does, I suggest you take a look at what I did. When I was learning all this stuff, I found that reading real script was the best way to learn things. Tutorials are wonderful, but seeing how this stuff is used practically is the best way to learn, in my opinion. That being said, my fix is sort of a weird hack, and it can probably be done in a cleaner way.


I was just trying to see if I could get the `id -u`==0 to work for me, that was before I knew it would work with the -u. Oh well.

The bashrc file is working great. The colors change, no annoying error messages. (:

As for adb shell, I guess that PS1 thing was actually working, I thought it would change the way the directories are being displayed, it did fix the $ and # issue though. Yeah it was using sh, but the directories are all named with the brackets before and after the actual name. (it's weird, because the issue only happens with the phone booted normal, in recovery it was working (as of last night) ).

But good work with the bashrc file. I thought I understood a good amount of the last one, but this one is just crazy! :)


Edit:

Okay, I'm trying out your script now, I think I was messing up with either the spacing, or (more likely) the brackets.

Hmm.. it was telling me Not Root for both, also in the line with the if [ `id -u`... part, it returns [1000: command not found ?

I'll keep fiddling around with it for a bit.
 
Okay, so here's the thing with id -u. It *does* in fact do exactly what we want it to do in a normal Linux distribution, that being, display the UID *only*. With busybox, or at least the version I'm using, it just displays the exact same thing that "id" does with no arguments. That makes it trickier, hence my ridiculous hack. That being said, it turns out I didn't look in the most obvious place. When looking for information like this, you should always look to environment variables, first. It turns out the the $EUID environment variable will always contain the UID of the user that you currently are. So, I fixed the .bashrc to use that, which is significantly simpler. It should work for everyone, but I'd appreciate it if you could verify that. It worked fine for me. In addition to that, I added something else to the prompt. Now, you will see in "<>" the exist status of the command you just ran after each command. If it's 0, the number stays green. If it's any other exit status, it will turn red, then switch back to green once you have an exist status of green again. Try it out. It's pretty handy, especially if you're not used to the whole "no output means successful command" deal.

As for adb, I don't quite understand what the problem is. Are you saying it's using sh? Because this won't work with sh, and that would make sense.

EDIT: It would help if I actually attached the file, wouldn't it?
 

Attachments

Okay, so here's the thing with id -u. It *does* in fact do exactly what we want it to do in a normal Linux distribution, that being, display the UID *only*. With busybox, or at least the version I'm using, it just displays the exact same thing that "id" does with no arguments. That makes it trickier, hence my ridiculous hack. That being said, it turns out I didn't look in the most obvious place. When looking for information like this, you should always look to environment variables, first. It turns out the the $EUID environment variable will always contain the UID of the user that you currently are. So, I fixed the .bashrc to use that, which is significantly simpler. It should work for everyone, but I'd appreciate it if you could verify that. It worked fine for me. In addition to that, I added something else to the prompt. Now, you will see in "<>" the exist status of the command you just ran after each command. If it's 0, the number stays green. If it's any other exit status, it will turn red, then switch back to green once you have an exist status of green again. Try it out. It's pretty handy, especially if you're not used to the whole "no output means successful command" deal.

As for adb, I don't quite understand what the problem is. Are you saying it's using sh? Because this won't work with sh, and that would make sense.

EDIT: It would help if I actually attached the file, wouldn't it?


Cool. I will try out the file later on.
Well, with my adb, it at the adb shell command, I get the sh prompt. Then typing 'ls' displays the directories, but instead of bin, mine is displaying things like [1;340embin[, all the directories are similar to that. I don't actually have it up and running right now.

But that is great about the $EUID,
 
Right, so if it's sh, it's not going to work. What happens if you just type "bash" from adb shell?
I'll post a screen shot, that'd be easier to explain.

adbshell.jpg


Okay, so the first green line is the default prompt (sh) with the ls command.
The next one is the bash prompt, and another ls command.

By the way, that new addition to the prompt (exists status I believe you called it) is very nice. It threw me off at first, but... it's catching on. And I think all of the .bashrc file is working great now. Kudos.
 
I'll post a screen shot, that'd be easier to explain.

View attachment 18131


Okay, so the first green line is the default prompt (sh) with the ls command.
The next one is the bash prompt, and another ls command.

By the way, that new addition to the prompt (exists status I believe you called it) is very nice. It threw me off at first, but... it's catching on. And I think all of the .bashrc file is working great now. Kudos.

1) Wow, that's pretty weird. So, did you ever try:

Code:
PS1=\$

to see if that fixes it while in adb? It doesn't seem to like the color codes in $PS1, even though it's bash. I'll have to look into why, later. There might be some way to detect that you're at that particular type of console, and have it do that automatically (probably through some environment variable or another).

2) Great, I'm glad you're actually using it :). I'll make sure to let you know of any further additions. I think you'll find that information like this in the prompt is very useful. If the screen was larger, I'd throw in more stuff, like the time. Having the time in the prompt is nice, because you can basically figure out how long it took a command to run, if you compare right. Unfortunately, we're working with small screens here, so it's hard to pack all that stuff in.
 
1) Wow, that's pretty weird. So, did you ever try:

Code:
PS1=\$
to see if that fixes it while in adb? It doesn't seem to like the color codes in $PS1, even though it's bash. I'll have to look into why, later. There might be some way to detect that you're at that particular type of console, and have it do that automatically (probably through some environment variable or another).

2) Great, I'm glad you're actually using it :). I'll make sure to let you know of any further additions. I think you'll find that information like this in the prompt is very useful. If the screen was larger, I'd throw in more stuff, like the time. Having the time in the prompt is nice, because you can basically figure out how long it took a command to run, if you compare right. Unfortunately, we're working with small screens here, so it's hard to pack all that stuff in.


No luck with the PS1=\$, but that's alright. I'm feeling more and more confident at with the CLI (recently set up ubuntu server for fun), so I basically know where I'm at most of the time. And if not, I can strain my eyes a bit trying to decipher that gibberish.
 
No luck with the PS1=\$, but that's alright. I'm feeling more and more confident at with the CLI (recently set up ubuntu server for fun), so I basically know where I'm at most of the time. And if not, I can strain my eyes a bit trying to decipher that gibberish.

What do you get if you run:

echo $PS1

Both before and after?

That's great that you're getting more and more into using the command line :). It's so much more convenient once you learn how to do everything. Some stuff will just become second nature. There is just a lot to learn. Feel free to ask me if you have any questions. If I don't know the answer, I can at least look it up. Trust me, I'm far from an expert.
 
What do you get if you run:

echo $PS1

Both before and after?

That's great that you're getting more and more into using the command line :). It's so much more convenient once you learn how to do everything. Some stuff will just become second nature. There is just a lot to learn. Feel free to ask me if you have any questions. If I don't know the answer, I can at least look it up. Trust me, I'm far from an expert.

Here's what I get in ADB.

Code:
echo $PS1
#
Code:
PS1=\$
Code:
echo $PS1
$


I might just have to take you up on that. :)
 
Once I get adb set up again (might be a while), I'll play around with the shell.
Hmm.. here's something interesting I was trying.
Code:
# ls | grep a
acct
app-cache
cache
data
default.prop
sdcard

You'll notice no strange characters.
Now, I tried adding the -L option to grep (displays all results not matched), but that doesn't seem to work right

Code:
# ls | grep -L 2332
ls | grep -L 2332
(standard input)

So, I don't really know what that means, I guess the problem seems to be lying somewhere with adb and some maybe this rom (miui), but I don't know. I just thought that would work, and then this issue would be (somewhat) resolved.
 
That has nothing to do with adb. That's just not the option you're looking for :). The option you're thinking of is -v, which will show non matching lines, rather than matching lines. A very common use of that would be if you're looking for a particular process. You would type something like:

ps -ef|grep process

The problem is that grep itself is a process, and shows up in the output, generally, so it's usually removed by doing this:

pe -ef|grep -v grep|grep process

The option you used, -L, is the opposite of the -l option, which suppresses normal output (the matched line) and shows the input file where the matched line was found. It can only be used effectively when input is from a file rather than stdin (where stdin is standard input). When you use a command like this:

command|command

the input to that second command is called standard input. That is what the -L is going to look at, and it's quite useless here. When you use grep like this:

grep -l pattern file

where pattern is the pattern you're looking for in a particular file, you can use -L. Of course, it's just going to return with the name of the file instead of the line, which is also useless here, but it becomes useful when you give multiple files for input. This is most useful when you do something like this:

grep -l pattern *

What that will do is search all files matched by * (all files in the current directory) for the pattern, and display a list of files where the pattern was found. You can use whatever expression you like, too (file*, for example, for all files that start with "file"). You were you using -L, so that would be the opposite. If you did:

grep -L pattern *

it would return with a list of files where the pattern was *not* found.

Once you start getting into the command line more, you'll realize just how powerful this sort of thing is when used with either the find command and the exec option, or the xargs command. I'll give you an exmaple:

find /some/path -type f -exec grep -l pattern {} \;

That will search (find) for all files (-type f) under /some/path, and all its subdirectories, then run (exec) whatever command you give after exec, which in this case is grep. So it will grep for your pattern on all files found in the directory structure under /some/path. The {} is a placeholder for input and is basically the list returned by find. Basically, this command is used to dump a list of files that contain your pattern. It's different from grep -l pattern * in that the find command will search the whole path structure you give rather than just the current directory.

Does that answer your question? :)
 
That has nothing to do with adb. That's just not the option you're looking for :). The option you're thinking of is -v, which will show non matching lines, rather than matching lines. A very common use of that would be if you're looking for a particular process. You would type something like:

ps -ef|grep process

The problem is that grep itself is a process, and shows up in the output, generally, so it's usually removed by doing this:

pe -ef|grep -v grep|grep process

The option you used, -L, is the opposite of the -l option, which suppresses normal output (the matched line) and shows the input file where the matched line was found. It can only be used effectively when input is from a file rather than stdin (where stdin is standard input). When you use a command like this:

command|command

the input to that second command is called standard input. That is what the -L is going to look at, and it's quite useless here. When you use grep like this:

grep -l pattern file

where pattern is the pattern you're looking for in a particular file, you can use -L. Of course, it's just going to return with the name of the file instead of the line, which is also useless here, but it becomes useful when you give multiple files for input. This is most useful when you do something like this:

grep -l pattern *

What that will do is search all files matched by * (all files in the current directory) for the pattern, and display a list of files where the pattern was found. You can use whatever expression you like, too (file*, for example, for all files that start with "file"). You were you using -L, so that would be the opposite. If you did:

grep -L pattern *

it would return with a list of files where the pattern was *not* found.

Once you start getting into the command line more, you'll realize just how powerful this sort of thing is when used with either the find command and the exec option, or the xargs command. I'll give you an exmaple:

find /some/path -type f -exec grep -l pattern {} \;

That will search (find) for all files (-type f) under /some/path, and all its subdirectories, then run (exec) whatever command you give after exec, which in this case is grep. So it will grep for your pattern on all files found in the directory structure under /some/path. The {} is a placeholder for input and is basically the list returned by find. Basically, this command is used to dump a list of files that contain your pattern. It's different from grep -l pattern * in that the find command will search the whole path structure you give rather than just the current directory.

Does that answer your question? :)

Awesome. That answers it perfectly. :)
So using the ls | grep -v dfdsadf returns all the output, which clears up my adb issue.

I'll look more into the find command, because that seems really useful.
 
Yeah, find is a useful command. You can do a lot with it when paired with exec. Another cool command is xargs. It is like find with exec, except it accepts stdin (from a pipe) and is used to do something to a list passed from a previous command. Look it up if you like.
 
Yeah, find is a useful command. You can do a lot with it when paired with exec. Another cool command is xargs. It is like find with exec, except it accepts stdin (from a pipe) and is used to do something to a list passed from a previous command. Look it up if you like.
I'll do that. From the sound of it...
ls *.txt | xargs -rm ? to remove all the .txt files..?

I'll load up the wikipedia and man page now. :D
 
I'll do that. From the sound of it...
ls *.txt | xargs -rm ? to remove all the .txt files..?

I'll load up the wikipedia and man page now. :D

Yes, that will do that, but you should use it for more complicated scenarios. You can accomplish the same thing by just doing this:

rm -f *.txt

You would want to use it for something similar to what you do with -exec in find. In fact, you can use it in place of that:

find . -type f -name *somepattern*|xargs rm
 
Yes, that will do that, but you should use it for more complicated scenarios. You can accomplish the same thing by just doing this:

rm -f *.txt

You would want to use it for something similar to what you do with -exec in find. In fact, you can use it in place of that:

find . -type f -name *somepattern*|xargs rm

lol, I wouldn't have used it that way, that was just my understanding of the command.

The wiki article says it's useful when the results return too many options. I'll keep reading, it seems that a lot of commands are showing up in my reading, and they are all seeming more and more useful. :)
 
lol, I wouldn't have used it that way, that was just my understanding of the command.

The wiki article says it's useful when the results return too many options. I'll keep reading, it seems that a lot of commands are showing up in my reading, and they are all seeming more and more useful. :)

Yes, that is the case where you would actually use the command you gave. Sometimes, there are too many files in a directory and you want to remove them all. If the argument list is too large for rm to handle, there are a dozen ways you could handle it. You could use find/exec, you could use xargs, you could even use a quick for loop.
 
Yes, that is the case where you would actually use the command you gave. Sometimes, there are too many files in a directory and you want to remove them all. If the argument list is too large for rm to handle, there are a dozen ways you could handle it. You could use find/exec, you could use xargs, you could even use a quick for loop.

A for loop... that is sounding a bit more intense. :eek:
 
A for loop... that is sounding a bit more intense. :eek:

for i in `ls`;do rm $i;done

Again, that actually isn't good for the "too many arguments" issue, as it will probably throw the same error. Xargs is good for that, but the for loops is great for a lot. When you get more comfortable with the command line, you can start reading about shell scripting. You'll use loops a lot :).
 
for i in `ls`;do rm $i;done

Again, that actually isn't good for the "too many arguments" issue, as it will probably throw the same error. Xargs is good for that, but the for loops is great for a lot. When you get more comfortable with the command line, you can start reading about shell scripting. You'll use loops a lot :).
I've just barely started doing scripting. Nothing too serious.

Mostly things along the lines of setting wireless settings via iwconfig at boot. (added a wirelessStart.sh to init.d)
I also play around with echoing various things. Because I'm a noob and echo gives results! lol (:
 
Hey, it's a start :). The best advice I can give is to just read existing scripts. See how other people have done things. When you know what a script ultimately does, you can get a good idea of how to script by seeing how somebody did it.
 
Yeah, I don't know it you can just copy that lib or not. There might be other dependencies, or reasons why it won't run correctly. I'm not a MIUI user, so I can't really comment without actually trying it out. Feel free to copy it, and see if it works. Certainly let me know if you get any other errors and what they are so we can do some troubleshooting.

i tried it my rom, copied to system/lib set permissions to -rw-rw-r and no problems
 
Back
Top Bottom