*** john_cephalopoda has joined #crux | 00:00 | |
*** qepeeqe has joined #crux | 00:02 | |
*** john_cephalopoda has quit IRC | 00:11 | |
*** qepeeqe has quit IRC | 00:12 | |
*** SiFuh has quit IRC | 01:10 | |
*** SiFuh has joined #crux | 01:10 | |
*** SiFuh has quit IRC | 01:23 | |
*** SiFuh has joined #crux | 01:25 | |
*** JanC_ has joined #crux | 01:28 | |
*** SiFuh has quit IRC | 01:37 | |
*** SiFuh has joined #crux | 01:38 | |
*** chinarul1zzz has quit IRC | 01:58 | |
*** chinarulezzz has joined #crux | 01:58 | |
*** _________mavric6 has quit IRC | 02:37 | |
*** _________mavric6 has joined #crux | 02:38 | |
*** tilman_ has joined #crux | 02:48 | |
*** john_cephalopoda has joined #crux | 05:40 | |
*** elderK has joined #crux | 06:04 | |
*** elderK has quit IRC | 06:04 | |
*** elderK has joined #crux | 06:04 | |
*** yjfopgnylocaofdl has joined #crux | 06:04 | |
*** Workster has quit IRC | 06:04 | |
*** Workster has joined #crux | 06:04 | |
*** g0relike-2 has quit IRC | 06:44 | |
*** g0relike has joined #crux | 06:45 | |
*** xvee has joined #crux | 06:58 | |
xvee | hi everyone. its been a while. | 06:58 |
---|---|---|
frinnst | hello | 07:02 |
*** emmett1 has joined #crux | 07:15 | |
*** xvee has quit IRC | 07:22 | |
*** workodera has joined #crux | 07:27 | |
*** Workster has quit IRC | 08:42 | |
*** umggsoymtiosctvt has joined #crux | 08:42 | |
*** Workster has joined #crux | 08:43 | |
*** emmett1 has quit IRC | 11:04 | |
joacim | every time i get emails about azure, i tick report as spam | 12:13 |
*** Workster has quit IRC | 12:29 | |
*** Workster has joined #crux | 12:30 | |
*** xx1973 has joined #crux | 12:52 | |
*** MNKyDeth has joined #crux | 13:07 | |
MNKyDeth | Using the 3.4-rc2 I am trying to install pulseaudio but ran into an issue. I see similar issues posted online but I can't seem to find anything to really reslove it. Was curious if anyone has run into this issue here with pulseaudio. https://pastebin.com/SC20DaZR | 13:12 |
frinnst | yeah | 13:14 |
frinnst | you can use my port for it, its patched there | 13:15 |
frinnst | just a second | 13:15 |
frinnst | https://planet-express.se/crux/ports/pulseaudio/ | 13:15 |
frinnst | rsync -aqz planet-express.se::ports/pulseaudio/ pulseaudio | 13:16 |
MNKyDeth | thank you, will try it momentarily | 13:17 |
jaeger | I emailed the maintainer a patch some time back but I guess he hasn't had time to work on it | 13:26 |
MNKyDeth | I do realize this is still RC as well. My goal was to get to a fully working system as I would want it and see what issues I had a long the way. Been a long while since I used Crux. Started back in the 2.0 or 2.1 days I think. Was using other stuff since around 2010. But I want to come back. | 13:30 |
MNKyDeth | frinnst: your package built and installed without issue. Thanks | 13:31 |
frinnst | cheers | 13:31 |
frinnst | i'll poke the pulseaudio maintainer | 13:31 |
*** crash_ has joined #crux | 14:09 | |
*** Kruppt has joined #crux | 14:14 | |
*** emmett1 has joined #crux | 14:21 | |
*** emmett1 has quit IRC | 14:37 | |
DaVinci | Don't know how interested anybody is in the performance of pkgutil, but testing did show up some interesting results. | 15:01 |
DaVinci | It looks like archives are being processed twice. Once for file contents, something like tar -t, and once for actual decompression. | 15:02 |
DaVinci | Almost trivial for a single package, I know, but when installing a distro, hundreds of ports are processed. | 15:03 |
ryuo | DaVinci: i doubt efficiency was ever a high priority, other than using C, since CRUX is primarily source based. the biggest overhead is building ports. | 15:05 |
ryuo | DaVinci: then again, all package managers do this. they have to know all the files being installed to check for any issues prior to extraction. | 15:06 |
ryuo | Namely, overlapping file pathes that aren't directories. | 15:06 |
DaVinci | Fair point, didn't consider that need for conflict resolution. | 15:06 |
DaVinci | It's not there in my problem. | 15:07 |
ryuo | i used to work on Frugalware's pacman. it's a bit more advanced than CRUX, but still this is a basic problem all have to address. | 15:07 |
DaVinci | True, it's just handled as part of my development process, so I don't worry about it that much, but I do use the pkg system to find them. | 15:08 |
ryuo | not sure what you're trying to come up with though. | 15:10 |
DaVinci | I collapse and expand ports all day, making sure they integrate correctly. | 15:10 |
ryuo | I do realize CRUX could use a PM library... current approach doesn't allow for scripting via library interface. | 15:10 |
DaVinci | That's hundreds of megabytes of archives, in and out. | 15:11 |
DaVinci | Takes forever. exhausting. | 15:11 |
ryuo | For what purpose? | 15:11 |
DaVinci | I make a framework that others use to build firmware images | 15:11 |
DaVinci | ThinStation | 15:11 |
ryuo | Oh, so CRUX is being used commercially too? | 15:12 |
DaVinci | Maybe.... | 15:12 |
ryuo | lol | 15:12 |
DaVinci | I support it, blindly to the public. | 15:12 |
DaVinci | ThinStation is totally free. | 15:13 |
ryuo | Maybe I can revise pkgutils to start exporting its core functionality as a C library with the CLI just becoming a user of it... | 15:13 |
*** Kruppt has quit IRC | 15:14 | |
DaVinci | I poked through the code a little. | 15:14 |
DaVinci | It would need more work to really do what I need. | 15:14 |
DaVinci | I 2x performance by assuming file paths are correct, and just listing the contents on decompress into the db. | 15:15 |
ryuo | DaVinci: Well, I could make behavior toggleable but the CLI would always keep them on. | 15:15 |
ryuo | As a safety feature. | 15:15 |
DaVinci | I also needed alternate db location, while expanding to root. | 15:16 |
ryuo | I'll see if they'll let me. C is something I specialized in. | 15:16 |
ryuo | frinnst: how much trouble would it be to get a redesign of pkgutils or w/e added? I've wanted to make it friendlier to 3rd party scripting for awhile now. | 15:17 |
DaVinci | Cool. I know it's possible, it would just take me weeks and weeks. I hacked a working solution out with tar. I hope it completely mimics pkgutil db creation :) | 15:17 |
frinnst | well you got revdep in | 15:18 |
frinnst | :> | 15:18 |
*** jue has joined #crux | 15:18 | |
frinnst | but pkgutils would need to be more vetted than that was (thats not to say that it needed more) | 15:18 |
*** workodera has quit IRC | 15:36 | |
ryuo | frinnst: i figured. | 15:47 |
ryuo | frinnst: i'll give it a spin one of these days. i've still got a week before i'm free from current obligations. | 15:52 |
cruxbot | [opt.git/3.3]: libidn: updated to 1.35 | 17:47 |
*** SiFuh has quit IRC | 18:27 | |
*** SiFuh has joined #crux | 18:30 | |
*** SiFuh has quit IRC | 18:37 | |
*** onodera has joined #crux | 18:39 | |
*** SiFuh has joined #crux | 18:43 | |
DaVinci | is there a tool for checking the integrity of the db, re-indexing? | 19:36 |
ryuo | DaVinci: not really? what would it check? | 19:37 |
ryuo | i mean, it's just a text file. | 19:38 |
DaVinci | I'm creating a db from concatenated db'lets, that are the output of tar and . Pkgfile. | 19:38 |
DaVinci | I just want to make sure it's all together right, the same way as if I had used pkgutil | 19:39 |
DaVinci | re-indexing would be the real one I need. | 19:39 |
DaVinci | then could diff against proper db. | 19:40 |
ryuo | you could do that with AWK, since it's just text records. | 19:40 |
DaVinci | context split? | 19:40 |
ryuo | Context split? | 19:41 |
DaVinci | Awk is like the last cli tool I never learned. How would I use it to re-index? I could maybe do something with csplit, break real db and fake db into files(per port record) then compare the tree. | 19:43 |
ryuo | well, you can use it to sort records. that is what you meant by reindex? | 19:43 |
DaVinci | Yes. | 19:43 |
DaVinci | Wasn't aware it did that. | 19:44 |
frinnst | oops. the libidn update broke some stuff | 19:44 |
frinnst | just a heads up there, check revdep after upgrading it | 19:44 |
ryuo | Or, maybe not to the same extent... | 19:46 |
ryuo | seems sorting isn't in its repertoitre. | 19:46 |
ryuo | DaVinci: can you spare a copy of a database? Perl is a quick option. | 19:47 |
DaVinci | spare a copy? | 19:47 |
DaVinci | Pretty tiny....where do you want it? | 19:47 |
ryuo | DaVinci: dpaste it. | 19:47 |
DaVinci | too big for dpaste | 20:00 |
ryuo | ok... | 20:01 |
ryuo | nevermind. gimme a bit. | 20:01 |
DaVinci | I can post to an http | 20:01 |
DaVinci | https://drive.google.com/file/d/1uXghBVOvDcrlH9AaTuDrguQ-OR2IRsUA/view?usp=sharing | 20:06 |
*** chinarulezzz has quit IRC | 20:59 | |
*** chinarul1zzz has joined #crux | 20:59 | |
joacim | i hear syfy has canceled the expanse | 21:12 |
joacim | i figured this would happen. they've canceled stuff for being expensive before | 21:12 |
jaeger | yeah :/ | 21:12 |
jaeger | they're going to try to get someone else to make it but I dunno how well that will go | 21:12 |
joacim | it is a popular show. was hoping someone would pick up dark matter, but that kinda started as a comic, so i guess it can be finished as one too | 21:20 |
joacim | for the expanse, it seems something that could be picked up by another | 21:20 |
jaeger | yeah | 21:25 |
MNKyDeth | I think the first season, maybe two... If there was two seasons were on Netflix or prime video. Maybe either service will pick it up? | 21:25 |
jaeger | The books are good, too :) | 21:25 |
ryuo | DaVinci: http://dpaste.com/1AHKC5H | 21:40 |
DaVinci | cool, ty, I'll play with that. | 21:42 |
ryuo | DaVinci: just feed it the names of any DB files, and it'll merge them into a single one, sorted by pkg name. | 21:42 |
ryuo | if none are given, it'll use stdin instead. | 21:43 |
DaVinci | I don't suppose your swift on resource limits. | 21:44 |
ryuo | DaVinci: ? | 21:45 |
ryuo | define resource limits. it has varying contexts. | 21:45 |
DaVinci | So I'm trying to run multiple tar -xvf in parallel. It goes for a while, then I think it's hitting a resource limit, parent gets a sig 7 and it all dies. | 21:47 |
DaVinci | Can get away with 2, but 3 or more blow up. | 21:47 |
ryuo | SIGBUS... i don't encounter that normally. | 21:48 |
ryuo | DaVinci: that isn't resource related. | 21:48 |
ryuo | it sounds like a program bug. | 21:49 |
ryuo | It's related to SIGSEGV. | 21:49 |
DaVinci | Why is that, all I change is the number of threads | 21:49 |
ryuo | https://en.wikipedia.org/wiki/Bus_error | 21:49 |
ryuo | No idea. | 21:49 |
DaVinci | fun | 21:51 |
ryuo | DaVinci: i take you're not a programmer? | 21:52 |
DaVinci | Shell stuff, a bit of hacking on whatever else touches it. | 21:52 |
DaVinci | Learned python, but I still don't want to touch it. | 21:53 |
ryuo | IOW, not really. | 21:58 |
DaVinci | lol, sigh, shell programming is still programming yo. | 21:59 |
ryuo | right... | 22:00 |
ryuo | lol | 22:00 |
ryuo | scripting. | 22:00 |
DaVinci | I think I figured it out. | 22:00 |
DaVinci | Replacing glibc, fine in a single thread, but not multiple. | 22:01 |
ryuo | i don't consider shell a real language because it does a fork+exec for nearly every thing it does. | 22:01 |
ryuo | Thread? Shell isn't threaded. | 22:01 |
ryuo | Do you mean multiple proceses? | 22:01 |
DaVinci | Yeah. | 22:01 |
DaVinci | xargs nproc | 22:01 |
ryuo | Threads are concurrenncy within a single process. | 22:02 |
ryuo | And that's just OS primitives. | 22:02 |
ryuo | Threads/Fibers can be done entirely in software. | 22:02 |
ryuo | most C software relies on kernel threads though. | 22:03 |
ryuo | using POSIX API. | 22:03 |
DaVinci | coolio | 22:03 |
ryuo | DaVinci: how old are you? | 22:04 |
DaVinci | 42 | 22:04 |
ryuo | Oh. You sound like you're 20 still... lol | 22:04 |
DaVinci | So flattering. | 22:04 |
DaVinci | At least someone thinks I'm young | 22:04 |
*** Workster has quit IRC | 22:05 | |
ryuo | don't get into C if you have a choice. | 22:05 |
*** Workster has joined #crux | 22:05 | |
ryuo | it'll drive you nuts if programming isn't your thing. | 22:05 |
ryuo | it's basically extreme programming as far as i'm concerned. | 22:06 |
DaVinci | Yeah, I'm a bit long in the tooth for it. | 22:06 |
DaVinci | I have hacked it, but always with trepidation. | 22:06 |
ryuo | it seems like every language has bizarre semantics that are rarely used. | 22:07 |
ryuo | Like, the comma operator in C. | 22:07 |
ryuo | What is the value of this expression: (x, y) | 22:07 |
ryuo | it's actually y. the comma operator evaluates both its operands, but only returns the right one. | 22:08 |
DaVinci | Hmmm. | 22:09 |
ryuo | (3, 4, 5) has the value 5. | 22:09 |
ryuo | when used in another expression. | 22:09 |
DaVinci | Oh sure, a ladder. | 22:09 |
DaVinci | or priority fallthrough. | 22:09 |
ryuo | it just lacks any real point. | 22:10 |
john_cephalopoda | There is some GNU thing that allows you to start multiple, concurrent processes in the shell. | 22:10 |
ryuo | john_cephalopoda: sending jobs to the background? | 22:10 |
john_cephalopoda | It's kinda like shell multithreading :รพ | 22:10 |
DaVinci | The point is that every language needs them. Even spoken ones. | 22:10 |
john_cephalopoda | ryuo: GNU parallel. | 22:11 |
ryuo | DaVinci: main reason some use threads is that they can share memory. | 22:11 |
ryuo | processes can't normally. | 22:12 |
ryuo | but, if you know what you're doing, POSIX shared memory is a thing. | 22:12 |
john_cephalopoda | Also IPC with sockets or pipes. | 22:12 |
DaVinci | Yeah, I'm really doing mp here, not mt | 22:12 |
ryuo | the only drawback to that is you need to define some kind of communication protocol. | 22:12 |
john_cephalopoda | I'd say that sockets or pipes are a saner solution to most IPC issues than shared mem. | 22:13 |
DaVinci | Which I don't want to do, cuz I hack lazy, let the os deal. | 22:13 |
ryuo | yes. | 22:13 |
ryuo | shared memory is easiest in the same process. | 22:13 |
ryuo | DaVinci: maybe you should try newlisp then. its preferred concurrency method is process based. | 22:14 |
john_cephalopoda | Within the process, yeah. | 22:14 |
ryuo | http://www.newlisp.org/ | 22:14 |
DaVinci | I worked it out with xargs. | 22:14 |
DaVinci | It's just a number now. got to 3, 4 is blowing up. | 22:14 |
ryuo | Tcl is also a weird one. | 22:16 |
ryuo | it's the only language i've seen that has shell-like syntax while not relying on external commands. | 22:16 |
ryuo | as its primary mode of operation. | 22:16 |
ryuo | set x [expr {3+4}] | 22:17 |
ryuo | puts $x | 22:17 |
ryuo | but, it doesn't have the same issue that shell does with whitespace. | 22:18 |
*** SiFuh has quit IRC | 22:22 | |
*** SiFuh has joined #crux | 22:22 | |
DaVinci | ryou: Got my install down from 5 minutes, to 53 seconds. Thanks for your help. | 22:36 |
ryuo | DaVinci: what were you doing before? a hack-job with shell? | 22:37 |
DaVinci | Oh, I still am. I still am. | 22:38 |
ryuo | DaVinci: well, shell has really bad performance for any real software. | 22:38 |
ryuo | revdep used to take 15 minutes before I did the C rewrite. | 22:38 |
ryuo | it was 100% shell. | 22:38 |
DaVinci | The shell is doing very very little. | 22:38 |
ryuo | ok. | 22:39 |
DaVinci | I just call other c compiled programs to do the heavy lifting. | 22:39 |
DaVinci | tar, xz, find. | 22:39 |
ryuo | just keep in mind if you do that a lot, you'll find your program slows to a crawl. | 22:39 |
ryuo | fork+exec isn't cheap. | 22:39 |
ryuo | it's also why CGI is no longer used. | 22:40 |
DaVinci | Eh, I am installing 892 ports in like 25 seconds. | 22:40 |
DaVinci | I'm happy. | 22:40 |
DaVinci | xz compressed no less. | 22:41 |
ryuo | i'm just giving you a warning. if your shell scripts end up running slow, consider how many programs you're executing to complete it. | 22:41 |
DaVinci | I do. | 22:41 |
DaVinci | ty | 22:41 |
DaVinci | I'm kind of a performance junky | 22:41 |
DaVinci | It usually comes down to how your write it, more than what with. | 22:42 |
DaVinci | sorta. | 22:42 |
ryuo | that's true of all languages, but more so with shell. | 22:42 |
DaVinci | I couldn't rewrite things like tar in shell, but I can glue it up to something right quick and in a hurry. | 22:42 |
ryuo | but shell doesn't allow for much beyond cobbling together external programs. | 22:43 |
ryuo | if you need to care about data structures, shell is *really* inadequate. | 22:43 |
DaVinci | I think that's actually quite a bit, but perspectives. | 22:43 |
ryuo | ah, i don't think in terms of external programs as much as i used to. | 22:44 |
ryuo | now it's primarily library APIs, and relying on CLIs to do that is a lot of work. | 22:44 |
ryuo | like, the old implementation of revdep couldn't really be optimized much. | 22:45 |
ryuo | the logic of what it did was too complex. | 22:45 |
ryuo | it had to be rewritten in a language that did most/all processing in process. | 22:45 |
ryuo | mostly because a lot of the logic relied on the data type of files. | 22:46 |
DaVinci | Ok. I do have some code that's like that. | 22:46 |
ryuo | using "file" all the time is an imprecise hack-job. | 22:47 |
ryuo | the only alternative i could think of is trying to use shell-builtins to check the file header. | 22:47 |
DaVinci | It could totally go faster in C, I'm sure. I mitigated most of the slowness, but it's still there on certain rare instances when the fast path fails. | 22:47 |
ryuo | DaVinci: shell will always be needed for ports, so there's that. | 22:48 |
ryuo | because building software basically requires cobbling together the right set of commands. | 22:48 |
ryuo | and it's highly variable how this is done. | 22:48 |
DaVinci | file is not really that bad. Especially if you trim the database. | 22:48 |
ryuo | DaVinci: i guess, but that's not an option for a general purpose distribution. | 22:49 |
ryuo | unless it supports different databases? | 22:49 |
ryuo | i never checked. | 22:49 |
DaVinci | No for sure not. But if your building a script that relies on file, you can make a custom db that only supports what your looking for, then file goes very fast. | 22:49 |
ryuo | DaVinci: I'd give TCL a look if i were you. you'll probably find a use for it when shell isn't enough. | 22:50 |
ryuo | Perl is also pretty good, but it's more complex than TCL. | 22:50 |
ryuo | TCL is one of the simplest languages i can think of. | 22:51 |
DaVinci | Allright. | 22:51 |
ryuo | both use sigils, the $ in shell. | 22:51 |
ryuo | eh, TCL isn't incredibly popular but neither is shell. | 22:52 |
ryuo | everything in TCL uses a command to perform operations. | 22:52 |
ryuo | Setting a variable, output, etc. | 22:52 |
ryuo | but most of them are internal to TCL. | 22:52 |
DaVinci | I actually heard that people calling themselves shell programmers is on the rise | 22:52 |
DaVinci | The need has increased. | 22:53 |
DaVinci | Might get even bigger with WSL | 22:53 |
ryuo | scripting and programming are related but largely different areas of focus. | 22:53 |
ryuo | There are shell libraries... but it's still something i consider hackish. | 22:53 |
ryuo | shell can't really support native data structures well. | 22:53 |
ryuo | though, BASH can be extended with C... | 22:54 |
ryuo | it's just not normally done. | 22:54 |
ryuo | you can load ELF shared objects to provide additional builtins. | 22:54 |
DaVinci | I agree with you there, but that just means that the interpreter doesn't support data structures. | 22:54 |
DaVinci | or complex data structures. | 22:55 |
ryuo | even C is far more capable in that area. | 22:55 |
DaVinci | You can implement most things. It just takes a crap load of code. | 22:55 |
ryuo | hence, why i usually consider shell only suitable for OS-level scripting or so. | 22:56 |
ryuo | it only excels at gluing external programs together. | 22:56 |
DaVinci | Maybe, depends I guess on how complex the data is. | 22:56 |
ryuo | No language can do this as well as shell can. | 22:56 |
DaVinci | A couple of fields......stay shell. More than than, consider a move. | 22:56 |
ryuo | even then, shell rarely directly works with field.s | 22:57 |
ryuo | it usually just combines other utilities that do. | 22:57 |
ryuo | and even then, they usually only support single-lines. | 22:57 |
ryuo | fields | 22:57 |
DaVinci | It gets complicated quickly, but always moving out of shell is a pain. | 22:57 |
ryuo | not always. it depends. | 22:58 |
ryuo | like, that script for sorting the pkg database. | 22:58 |
ryuo | it's just general stuff. nothing unique really like xz or gzip. | 22:58 |
ryuo | well. there's some obscure shell behavior. | 22:59 |
ryuo | do you know what happens if you quote the name of a here-document? | 22:59 |
ryuo | cat << EOF | 23:00 |
ryuo | ... | 23:00 |
ryuo | EOF | 23:00 |
ryuo | to: | 23:00 |
ryuo | cat << 'EOF' | 23:00 |
ryuo | ... | 23:00 |
ryuo | EOF | 23:00 |
ryuo | if you're going to stay with shell, may as well learn how it works. | 23:01 |
DaVinci | Is that a vs, or a nested? | 23:01 |
ryuo | VS? | 23:01 |
DaVinci | verses | 23:01 |
ryuo | versuses. | 23:01 |
ryuo | they're not nested. | 23:02 |
DaVinci | 'EOF' means, don't expand variables between here and EOF. | 23:02 |
ryuo | i guess that's a valid answer. i look at it as suppressing evaluation. it takes the whole context literally. | 23:02 |
ryuo | http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html | 23:02 |
ryuo | some other favorites of mine... | 23:03 |
ryuo | ${HOME#*:} | 23:03 |
ryuo | err | 23:03 |
ryuo | PATH | 23:03 |
ryuo | echo ${PATH##*:} | 23:03 |
ryuo | one of the few ways to modify strings w/o using an external commnad. | 23:04 |
DaVinci | slicing is fun. | 23:04 |
ryuo | ${PATH:-FOO} | 23:04 |
ryuo | you familiar with this? | 23:05 |
ryuo | one of my favorites | 23:05 |
DaVinci | Not exactly | 23:05 |
ryuo | ${FILE/.bar/.foo} | 23:05 |
ryuo | DaVinci: ah, it does different things based on the status of PATH. | 23:06 |
DaVinci | So how old are you? | 23:06 |
ryuo | see 2.6.2 of that link | 23:06 |
ryuo | 30. | 23:06 |
ryuo | but i think this is non-portable. | 23:07 |
ryuo | ${FILE/.bar/.foo} | 23:07 |
ryuo | ${FILE#.bar}.foo | 23:07 |
ryuo | :P | 23:07 |
ryuo | err | 23:07 |
ryuo | % | 23:07 |
ryuo | ${FILE%.bar}.foo | 23:07 |
DaVinci | that looks like cut .bar and add .foo | 23:08 |
ryuo | from the end, yes. it's basically: | 23:08 |
ryuo | echo "$FILE" | sed 's/[.]bar$/.foo/' | 23:09 |
DaVinci | same | 23:09 |
ryuo | useful for substituting file extensions. | 23:09 |
ryuo | it's more formally called sub-string substitution. | 23:09 |
DaVinci | I would have just done \. instead of a full [.] | 23:09 |
ryuo | DaVinci: i avoided \ because it's a nightmare to embed it correctly. | 23:10 |
DaVinci | can always change the delimiter | | 23:10 |
ryuo | it's not relevant to the sed delimiter. | 23:10 |
ryuo | / is not \ | 23:10 |
ryuo | it's because of how shells ar. | 23:11 |
ryuo | are* | 23:11 |
ryuo | you have to do just the right amount of escaping so it makes it to sed correctly. | 23:11 |
ryuo | Hm | 23:11 |
ryuo | I guess it doesn't matter for single-quotes... | 23:11 |
ryuo | i just hate back-slashes. | 23:12 |
DaVinci | Yeah, got a thing against windows :) | 23:12 |
DaVinci | Thats where most people get that tick. | 23:12 |
ryuo | nah, i've never really done any windows programming. | 23:13 |
ryuo | just some crap for school if that | 23:13 |
ryuo | DaVinci: trivia: what's the difference between `echo foo` and $(echo foo)? | 23:15 |
DaVinci | One comes from a whole new instance, but the both try and execute foo | 23:17 |
DaVinci | \/the/they/ | 23:18 |
ryuo | DaVinci: they're both executed in sub-processes. | 23:23 |
ryuo | DaVinci: but you can't nest ``s. | 23:23 |
ryuo | try this: | 23:23 |
ryuo | `echo `cat /dev/null`` | 23:23 |
ryuo | it should output an empty line if it nests. | 23:23 |
ryuo | $(echo $(cat /dev/null)) | 23:24 |
ryuo | DaVinci: also, if you need to do integer arithmetic, use $(( ))s. | 23:24 |
ryuo | it performs it in the same process as the shell. | 23:25 |
DaVinci | math is for nerds. | 23:31 |
frinnst | holy backlog batman | 23:35 |
ryuo | frinnst: i imagine your work backlog makes it pale by comparison. | 23:41 |
*** john_cephalopoda has quit IRC | 23:47 | |
*** john_cephalopoda has joined #crux | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!