Bash Patterns

So this is, I guess, on Bash, general concepts and stuff. At any rate, I'm Sean. So yeah, I assume that you kind of are familiar with, well, actually, this is DSH. There we go. Bash command line-ish.

So, yeah, lots of scripts seem to be written for shell, and they are interpreted by bash. And it doesn't look as clean or run as well as it could if it was in bash. That's what you're assuming, write bash, not shell. If you want portability, slash bin slash sh, and write shell, but that's not what this is about.

There's lots of stuff for lots of manual information that's for Bash that's not in the manual pages necessarily. They are help that is internal to Bash. Samples.

Doing the first part of these, but at any rate, you can see that there's help files that are not man pages.

that are a set go in bash enable, which is interesting. You can actually make the bash modules kind of like XS and Perl or Node or whatnot, Python. You have the same type of thing, bash, and that allows you to load stuff. I'm not going to talk about that at all, but just to note that it's there. Command precedents. Right. So this is basically what bash looks for whenever you type a command. It first looks for functions, aliases. Actually, if I have time at the end, I'll show how I've used this with a Vim to generally load what I want to load with VI or Vim. And then I can not do that using the slash before. So I

basically alias a function. I call vimfunc and then . So if you use the old style proof,

is a bash built in, but it is also a command.

Right, so in bash you can do the expansion. Don't cheat, you can help it, whatever. Not in bash. Do that instead, looks nicer, runs faster.

All the things that use iteration, iterate over words in bash, a word is generally separated by space or a tab, whatnot. So anything that, any string that you give that has separations in it, go one to the next. Doesn't care that much.

You can see that when you echo out a string. It does that. And then you can, that's echo versus seek.

The other thing about the bash expansion like that is it will expand the whole word when you do that. So if you want to iterate over a name,

Maybe you have a list of computers, right? And you have node 1 through 1,000, right? And just go through that and dig what it does up to. The limitation is the amount of data you can have on a command line after a

bag or so.

Anybody has looked at the OSCP, they have a Python script at the beginning where they try to fuzz a mail server, I think. You can do this in Bash, and it actually works faster than the Python version, I'm guessing, to an extent after you get out far enough, Bash will go efficiency versus Python. Yeah. Yeah, you can.

Also capital, actually. Nope. So, at any rate, same range. Yeah, you can do .c.

or another comma? Nope. Probably not the same one, so I can do

that, that. I think I might have to include it in another one. There you go. Yeah. Oh, well. Right, yeah, not exactly password generator, but yeah. Again, fuzzed off. Right.

Right, so, as far as looping goes, you can, because I guess a lot of the reason people use seek is because of, you can tell evens or odds, whatnot, when you do that. But you can also have a T-Style loop and do the same thing you can do there.

Math. There's still reasons to pipe into BC if you need. really, really fancy stuff, but generally not.

So, right, there's two bash built-ins, command type. They do basically the same thing. I think type loads the, loads the command into hash the other way around, I don't remember, the bash that it uses for future lookups. But at any rate, they're basically the same, just minor differences.

But at any rate, so yeah, there's no reason to do that if statement. I just did it to show

It even works with bash, the built-ins. It'll work with aliases, whatever. Make sure that things are there before you start processing a script. Get five minutes into it and it's not there.

Probably want to get any of the script. This is on GitHub, so you can go and look this up, see where the slides are. This is actually . Probably want to include a die function because those programming languages have that and probably want to fail out. That's there.

Right, so it's good to not have people editing your script because

to have people, to allow people to have configuration files so that they don't have to scroll through a bunch of code and figure out where things go, whatever. The easy way to include that is just source it as script material so that you can do variable equals string, right? Your Debian init stuff will do that. I don't remember where it came. that stuff, but anyway. It does that type of thing.

So just, yeah, so you do want to keep that configuration files here as the same security as your actual script. So don't allow everybody to edit your config data if you're expecting the script to be run as root. Probably. Right, just explains. You can do horrible things.

Actually, in fact. Right, well, yeah, and you can also output. So I generally redirect everything that's from source material to dev-mail.

I think it does, but maybe not. That's with what?

Yep, yep, yep. That's correct.

So, yeah, I'll correct. Good catch.

Right, so grabbing files.

The $pren less than is basically the same as $cat, or $pren cat of file. Works the same way. It's just the bash shorthand.

So that works. So while works the same, basically, as map file. MapFile allows you to do offsets. You can also obviously do the offset with a while loop.

If you are not transforming any data, they work the same speed. If you're doing a light transform on the data, then the map file and the function before you load it into an array works slightly faster and is, I guess if you know what you're looking at, is cleaner.

of reading the code. Our audience. Making the same defaults. Right, so most scripts, check if an array exists or a variable exists and define it kind of long. I like this a little bit better. It can line up things a little better and not as much typing. up as much.

So yeah showing changing the file separator and taking a column out of CSV, same with the

So I guess string manipulation, I do like in Bash better than trying to use other languages because it looks cleaner. Take it from other commands or string, whatever.

Right, so Bash doesn't have that many variables. You're generally going to use a string or an array. I used a hash, but I think it's 3.2 something. So I don't, the older OSX versions didn't support it, so at any rate, depending on where you're running, also, RHEL 6.5 doesn't support it, so. A lot of things you're, it's gonna be limited as far as some of the variable types.

So this is just, if you want to test this stuff, like, yeah, use declare-p, declare-f to look at what data is where quite often. Going it there. Again, defining it based on how you're using it. Works just fine as well, obviously. And it just starts to get into variable substitution and arrays. You can do quite a lot with that. And using it on the command line works quite well. Also, obviously, a lot of stuff

So actually, first that slide and that slide. But anyway, that's just showing basically you can't do that with an alias, right? Because it's just going to substitute what you have. You need to, in that command, substitute or put stuff in the middle of a command, right? So I do actually have that. I use the sh as my shell.

And right, so I use this quite often. Go to SSH into a box, start to need the pseudo to do something, to end up with a modified environment, whatnot, and putting stuff in there is quite difficult.

Quite easily get the function in there and then just run it. It works flawlessly.

All right. And there's an example of a reference.

Array and a function like that in the middle. So function, array, and then a string, you can take that in.

That was actually important showing basically if you run a function as a bash, a subshell, it's really slow. So if you're gonna return something, like return it as a global variable, it works a lot faster. Not as clean, but you'll notice improvements or anything about speed. Right, you can

Rename functions on the fly. Debugging. You can do this all the time at the beginning of a script or in a function. Try not to do that in production because the dash E will relies on the return code. It'll kill the shell is basically what I'm showing. script immediately if you, stuff like that, and that's obviously not an error, that's just reducing a variable pass error.

In fact, I should have done this better. You can, what I've done a lot with commands, you can make a command a function, and then you can see what the command's saying before it's passing into the command.

bonus, right, SSH. Be careful with SSH because I built an environment by messing with SSH. But SSH wants a file. Some other things want a file. And use your file descriptor or with SSH, that's just giving it no configuration file. Once one, give it no. And it works by default stuff.

Testing different multiple shells with a command. Nice. Found on mailing list. Timing stuff. Quite easy in Bash.

They don't optimize bash grips. Thanks. There's me. Perfectly timed. Resources. Mainly putting them there because this is on a GitHub page.

I guess I should. Right. So, oh, and I have no internet. So, there you go.