26 ms·
The time might come when we add some JSON specific command line options
- bonkabonka 5y agoI would prefer to use the --json flag to provide syntactic sugar for setting the content type and accepts headers and leave the marshaling of data to a separate tool. Or if it has to be baked in, refactor `jo` into `libjo` and a CLI wrapper so that the two tools behave the same way.
- abotsis 5y agoWhat happened to “Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".”? If it’s too tough to integrate with other tools like jq, maybe that could provide for a better outcome.
- pphysch 5y agoPragmatism happened. Pragmatism always beats dogma in the long run.
- softwarebeware 5y ago100%! People keep forgetting about the Unix Philosophy.
- pixel_tracing 5y agoHow about opening up an Vim or Nano like editor with an option flag —editor where I can just paste the request body instead of passing flags, etc.?
- svnpenn 5y agoShouldn't this be a GitHub issue or GitHub discussion? Wiki is a weird format to use for a proposal.
- JRGC1 5y agoPerhaps use an existing JSON command line tool and piping it into Curl?
- drewda 5y agoI like using the httpie CLI, in part because it has a nice interface for sending JSON and receiving JSON: https://httpie.io/docs/cli/json https://httpie.io/docs/cli/json
- aesyondu 5y agoI wish I knew about this feature sooner. I've been using: ``` echo { "my": "json" } | http post localhost/endpoint ```
- blibble 5y agohopefully we'll be getting command line arguments to build up XML documents soon too.....? (not serious)
- fhd2 5y agoMaybe you're being downvoted because you're just not thinking big enough? How about first class SOAP support?
- gumby 5y agoJSON is underspecified, leading to various incompatibilities between implementations. Because cURL is so ubiquitous, whatever Daniel implements may become the de facto standard.
- ch4s3 5y agoI think that's the most interesting implication here. I really hope he lands on something suitable.
- Diggsey 5y agoJSON isn't under-specified, you can tell if something's valid JSON just based on the rules here: http://www.json.org/json-en.html http://www.json.org/json-en.html. The mapping of the JSON data model to the data models found in various languages is what's ambiguous. Which is not impacted by curl supporting JSON in the slightest: - The `--json` option only adds a content-type header, it doesn't alter the transmitted data at all. - The `--jp` option has a bespoke format that's not part of the JSON spec, and which doesn't actually depend on a specific data model, it's just string manipulation.
- gumby 5y agoSee a detailed reply to a parallel comment. Also, —jp is actually generating a JSON.
- Diggsey 5y agoNumbers are the main thing I assumed you were talking about: the JSON spec is clear though, numbers can be arbitrarily long. The problem is not with the JSON spec, the problem is when you are converting from one data model to another. Any program which claims to perfectly round-trip the JSON data-model should support arbitrarily long numbers, there's no ambiguity in the spec about that. If you are only parsing JSON as a means to encode your own data-model, then there's no obligation to support arbitrary precision, but users should not expect to be able to round-trip arbitrary JSON data. AFAICT, `--jp` doesn't do anything which would affect the length of supported numbers, even though it's generating JSON.
- Zamicol 5y agoI use cURL for local development with JSON cookies and I think it's perfectly adequate for that purpose. curl --insecure --cookie test_cookie='{"test":"bob"}' https://localhost:8081/ https://localhost:8081/
- pbiggar 5y agoYou forgot `-H "Content-type: application/json; charset=utf-8"`
- edoceo 5y agoNo charset on this mime type.
- pbiggar 5y agoTIL! Seems to be a quite confused topic as many things (it seems for example some java servers) even require it, but you do seem to be right, as JSON must always be utf8.
- Zamicol 5y ago--cookie puts the value of the cookie in the header. Host: localhost:8081 Accept: / Cookie: test_cookie={"test":"bob"} User-Agent: curl/7.74.0
- MrStonedOne 5y ago
- mdoms 5y agoGood news, you can keep doing it that way.
- svnpenn 5y agoI think its bad practice to only quote part of the argument like that.
- 5y ago
- jeremyjh 5y agoI know I've done the quoting dance before, while exploring an API in one project I resorted to using zsh heredocs to build the payload argument to avoid all quoting issues. I'm sure there is a better way already but it sounds nice to have this built into curl as its so common.
- CobrastanJorji 5y agoIf you regularly do command line JSON requests, I'm a big fan of HTTPie. It's so much easier to use correctly. https://httpie.io/docs/cli/examples https://httpie.io/docs/cli/examples For example, here's a JSONy POST request with cURL: curl -s -H "Content-Type: application/json" -X POST https://api.ctl.io/v2/authentication/login https://api.ctl.io/v2/authentication/login --data '{"username":"YOUR.USERNAME","password":"YOUR.PASSWORD"}' Here's that same request with HTTPie: http POST https://api.ctl.io/v2/authentication/login https://api.ctl.io/v2/authentication/login username=YOUR.USERNAME password=YOUR.PASSWORD
- db65edfc7996 5y agoI have recently been trying a port of HTTPie in Rust, xh [0] (which is needlessly hard to find in a websearch). I am a Python guy, but love having single executable tools. [0] https://github.com/ducaale/xh https://github.com/ducaale/xh
- petepete 5y agoxh is great, just like HTTPie but incredibly fast. I alias it to http so it's memorable and the commands make more sense though.
- kbd 5y agoHappy to hear about xh, thanks for mentioning it. I recently ran into a problem where HTTPie didn't support HTTP/2, so I had to fall back to curl. The ticket for HTTP/2 in HTTPie is still open https://github.com/httpie/httpie/issues/692 https://github.com/httpie/httpie/issues/692 Happy to see that xh supports HTTP/2 out of the box.
- mimimi31 5y agoI think --data implies -X POST, so that part at least would be unnecessary.
- CobrastanJorji 5y agoAhh, I believe you're right. "PUT" would have been a better example, in that case. But I suppose getting the cURL syntax wrong helps my point that I find the cURL syntax confusing.
- otar 5y agoHmm… any actual use cases of this? I don’t find curl —jp a=b to be better than directly sending a payload on a HTTP resource.
- masklinn 5y ago> Hmm… any actual use cases of this? ... interacting with APIs using cURL? > I don’t find curl —jp a=b to be better than directly sending a payload on a HTTP resource Getting JSON syntax right, error free, by hand, in a terminal, is not easy. The current equivalent of an eventual `curl --jp a=b` is curl -s -H "Content-Type: application/json" --data '{"a":"b"}' that's a lot of opportunities for getting it wrong.
- ChrisOstler 5y agoAnd even more when the JSON is dynamic, and not static: curl -jp a="$B"
- 8n4vidtmkvmk 5y agoits also pretty trivial to alias/wrap that tho
- naikrovek 5y ago> Getting JSON syntax right, error free, by hand, in a terminal, is not easy. you are right and I wonder why shells haven't done anything to address this. Fish might, actually. colorization isn't really useful in aiding comprehension, but colorization is good at giving an indicator that there is a parse error somewhere.
- mkdirp 5y agoThe issue is probably related to quotations among other shell related things. Observe: NAME=taterman EMAIL=sweettaterhater@taterman.com curl --jp "user=$NAME" --jp "email=$EMAIL" http://getdemtaters.com vs curl -d "{\"user:\"$NAME\",\"email\":\"$EMAIL\"}" http://getdemtaters.com Even adding jq to requirements doesn't make it that much better: jq -n --arg name "$NAME" --arg email "$EMAIL" '{ "user": $name, "email": $email }' | curl -d @-
- stackedinserter 5y agoAlso, setting "content-type: application/json" in POST/PUT/PATCH requests would be helpful.
- makapuf 5y agoYes I dont understand why accept header is set and not content type which seems even more obvious, any reason ?
- kodah 5y agoI was wondering, "Why not pipe output to JQ" up until I read this: > A not insignificant amount of people on stackoverflow etc have problems to send correct JSON with curl and to get the quoting done right, as json uses double-qoutes by itself and shells don't expand variables within single quotes etc. It's about sanitized inputs.
- masklinn 5y ago> It's about sanitized inputs. Less sanitized and more correctly formatted. Writing literal JSON by hand at the CLI is not fun.
- oconnor663 5y agoIf I really had to get some JSON into a Bash script, and I couldn't just stick it in a file, I'd probably use a "heredoc" something like this: $ my_json="$(cat <<EOF > { > "foo": "bar", > "baz": 42 > } > EOF > )" $ echo "$my_json" { "foo": "bar", "baz": 42 } But I definitely didn't remember how to handle the closing paren and closing quote correctly, and I had to google for an example just now. So I'm not allowed to say this is easy to remember :)
- aidenn0 5y agoRandom bit of trivia: on ksh you can do foo="$(cat <<EOF)" whatever EOF This is left undefined in the POSIX standard and bourne shells don't allow it.
- _wolfie_ 5y agoThat is why you use jq --arg for the input instead of crafting it by string concatenation. data=$(jq -n \ --arg title 'what"ever' \ --arg endpoint 'foo"bar' \ '{ "title": $title, "endpoint": $endpoint, "enabled": true }')
- aesyondu 5y ago
- tastroder 5y agodupe of https://news.ycombinator.com/item?id=30011382 https://news.ycombinator.com/item?id=30011382
- diogenesjunior 5y agoIt's not a dupe. They each link to pages talkin about a similar topic, but the content is entirely different.
- aequitas 5y agoThe other post's page literally links to this post's page. So we're discussing the same here, just with less context.
- diogenesjunior 5y agoStill doesn't make it a dupe.
- cpach 5y agoI betcha $5 that 'dang would consider it a dupe.
- diogenesjunior 5y agodang != god
- CRConrad 5y agoMaybe not in the larger universe, but here...?
- advisedwang 5y agoSome of the replies say this is a layer violation: HTTP doesn't care about JSON so curl shouldn't either. But you have to add Content-type and Accept headers when working in JSON, which I personally often forget, so I think this does make sense.
- matt_kantor 5y agoThere's also plenty of stuff like this already in curl: --aws-sigv4, --data-urlencode, --form, --metalink, --oauth2-bearer, etc.
- pbiggar 5y agoThis is great. When a new user uses Darklang, we want them to be able to make JSON API requests quickly and easily, and there aren't great client-side tools for that that you can expect users to have installed. giving them a big long curl command is no fun, but `curl --json 'the-body' would be amazing`
- 999900000999 5y agoOn one hand, this is awesome. But aren't there also several command line utilities which already support JSON. Why cram new stuff into such an industry standard tool?
- ollien 5y agoYou kind of said it yourself: it's an industry standard tool, so it will (almost) always be available.
- 999900000999 5y agoMy concern is they'll accidentally break something.
- bryanlarsen 5y agoI trust Daniel Stenberg to not break something more than I trust any other tool that currently does JSON.
- masklinn 5y ago> But aren't there also several command line utilities which already support JSON. There are command line utilities which consume, query, or format json. But aside from e.g. httpie (which is essentially a competitor to Curl), which "several command-line utilities" make authoring JSON easy and convenient? Because if you check point (3), the link, and the paragraph before it, this is entirely about sending valid JSON (ideally with the correct headers). In fact the second section of the link in question literally states: > # JSON response > Not particular handling. Pipe output to jq or similar.
- 999900000999 5y agoYou can author your JSON in Postman and then export to Curl. Infact you can run postman on the command line https://learning.postman.com/docs/running-collections/using-newman-cli/command-line-integration-with-newman/ https://learning.postman.com/docs/running-collections/using-... Or you can write your own script in Python to do this. I really don't like adding new functionality to standardized tools. It's just risky. Make an extension, call it CURLson, but don't cram it into curl.
- svnpenn 5y agoShouldn't this be a GitHub issue or GitHub discussion: https://github.com/curl/curl/wiki/JSON https://github.com/curl/curl/wiki/JSON Wiki is a weird format to use for a proposal.
- naikrovek 5y agothis page started before discussions were a thing, and issues were never a good fit for this kind of thing.
- mg 5y agoI would rather write a new tool - say jcurl - which uses curl under the hood. As a user I would not expect curl to have json functionality. And as a developer I would prefer to have one codebase deal with http and another one with json.
- jrockway 5y agoCurl has LDAP support, email support, etc. JSON is not a stretch of the imagination by any means.
- pixl97 5y agoWhen dealing with support on someones docker image, for me it's far better to have this in one utility. Yea, you can write a command with the current version, but cutting it down to -jp will be much easier.
- tester756 5y agoGreat to see that author is open minded and pragmatic
- a45a33s 5y agowill libcurl have built in json support or just the command line?
- ainar-g 5y agoI feel like if you only want to make a single JSON request, a simple curl invocation with the JSON data in single quotes or in a file should be enough. And if you make many different JSON requests, you're probably much better off with one of the alternative tools. Related to the second point, I really wish more people put more time into creating tools for their testers. Shell/Ruby/Python/Perl scripts that are custom-made for the specific service they're testing and provides better UI. So that instead of a sequence of curl invocations, logins, and error-prone copy-pasting, people could just: test-my-service --user j.doe:hunter2 --api comments/create --param body="hello world"
- greenn 5y agoSounds like this idea is limited to the curl tool and wouldn't add anything to libcurl, which is great. I'd prefer libcurl leaving JSON to other libraries. I use bash variables inside JSON with curl all the time, which leads to string escape screw ups. I know there are alternatives that make testing REST + JSON easier, but since our software uses libcurl in production I prefer to test with curl to keep things consistent.
- er0k 5y agoCheck out curlie[0] which is really great and already does this. It's essentially a wrapper for curl with JSON support. [ 0 ] https://github.com/rs/curlie https://github.com/rs/curlie
- petters 5y ago> --jp a=b --jp c=d --jp e=2 --jp f=false Uh oh, this looks like it would have the problems of yaml. The data type changes based on the provided string.
- zeroimpl 5y agoExactly. At least make it something like --jps for strings and --jpn for numbers.
- leifg 5y agoTo everyone saying "just use tool x for this": the advantage of curl is that is so widely available. For your development laptop you can install anything you want but more often than not you need to log into a EC2 instance, a Docker container you name it. Curl is often pre installed or very easy to install. I know it's usually not an up to date version but as time goes by you will be able to rely on this feature on pretty much any machine.
- deleted 5y ago[deleted]
- faeriechangling 5y agoThere's no feature you cannot justify adding to curl on the basis that it would be convenient to have it on any system.
- justin_oaks 5y agoI can see this being useful, but I'm not looking forward to the list of command line options being even longer. The output of "curl --help" on my system is already 212 lines long. I wish the curl command was split such that different protocols had different commands. I REALLY don't want to see a list of FTP specific command line options whenever I'm just trying to look up a lesser-used HTTP option. That said, this is really a minor gripe compared to just how useful curl has been for me over the years.
- prpl 5y agoI always think of a perm everyone I do “man curl”, which is more often than I’d like.
- jcul 5y agoI don't think I'll be able to forget this going forward any time I check the curl manpage!
- kortex 5y agoI'm already well past the stage of using moar/micro/[rip]grep to scan through curl's manpage and find what I need. OTOH, if you ignore using curl to GET resources to download, >90% of my curl usage is slinging json, and often involves interpolating strings and hence copy-pasting, so this feature would be immediately useful to me. Curl is kind of the swiss army knife of the web so I don't think a long manpage is out of line.
- makapuf 5y agoYes,a multitool like busybox with separate subcommand names would seem nice
- chrismeller 5y agoThank $deity. Jq suuuucks.
- naikrovek 5y agoit requires learning the query language, sure, but I would not say that it "suuuucks" by any means. maybe learning the query syntax sucks.
- chrismeller 5y agoOk, I will further explain my complaints. There are two standards for selecting an element in a document. XPath and, ugh, JQuery. JQuery is easy for newbies. XPath is the “real solution”. JQ uses neither of these. Why? Who the hell knows.
- Macha 5y agoI'm indifferent if they do this or not, can always use pipes and jq, but if they do, I hope the json-part option uses some syntax that's a subset of jsonpath and/or jq, so I don't have to understand a third syntax when people start using this.
- draw_down 5y ago
- hnarn 5y agoIn the linked github wiki there's an example of the syntax of the suggested --jp flag used to pass key-value pairs and put them together as a JSON object:[1] --jp a=b --jp c=d --jp e=2 --jp f=false Gives: { "a": "b", "c": "d", "e": 2, "f": false } --jp map=europe --jp prime[]=13 --jp prime[]=17 --jp target[x]=-10 --jp target[y]=32 Gives: { "map": "europe", "prime": [ 13, 17 ], "target": { "x": -10, "y": 32 } } While this is neat, I suppose, it seems like such a waste that the first one isn't given as: --jp a=b,c=d,e=2,f=false And the second as: --jp map=europe --jp prime[]=13,17 --jp target[]=x:-10,y:32 ...or similar. The repetition kind of bothers me. [1]: https://github.com/curl/curl/wiki/JSON https://github.com/curl/curl/wiki/JSON
- jffry 5y agoThen you wouldn't be able to reliably use shell substitution to pass in values, which is a pity. The issue being if $var contained commas, like var="foo,y=bar" curl --jp "x=$var" Then allowing comma-separated field=value pairs within a single --jp argument would cause non-obvious changing behavior
- hnarn 5y agoYou could possibly solve it by supporting single quotes for value containment: curl --jp "x='$var'" Gives: curl --jp "x='foo,y=bar'" Assuming that is what you meant. Isn’t this normally how these things are handled in unix shells? That and escaping which probably doesn’t apply here. I don’t know what the best way to implement this would be, but the current proposal looks so weird for me that I’m either completely missing something or it’s wildly unnecessary.
- jffry 5y agoIf you do something like single quotes then you can no longer use the shell's abilities to properly pass in escaped values like this: bash$ foo=this\"test\" bash$ echo "value of \$foo is: $foo" value of $foo is: this"test" If we're throwing away the ability to let the shell handle escaping properly then there's really no point to --jq at all versus just manually attempting to cobble together JSON directly
- intrasight 5y agoI now use a C# REPL like csharp-script rather than such task specific scripts such as curl. It's more flexible, powerful, and consistent.
- hn_throwaway_99 5y agoThe --jp (json part) command line option, described at https://github.com/curl/curl/wiki/JSON https://github.com/curl/curl/wiki/JSON, has "anti-pattern" written all over it to me. Why introduce some specific, curl-only wonky-ish version of JSON? Is this any easier to remember than normal JSON? I mean, right now, I use cURL all the time with JSON posts, just doing something like -d '{ "foo": "bar", "zed": "yow" }' The proposed --jp flag seems worse to me in every way. (Note I do like the --json as just syntactic sugar for -H "Accept: application/json" -d <jsonBody>)
- kortex 5y ago> Is this any easier to remember than normal JSON? Yeah, actually it is. It's immediately intuitive to me. It makes string interpolation way easier. Quick, how do you do -d {object} and pass in environment variables with correct string escaping? Do you start with single quote or double quote? Where do I put backslashes? Bash vs zsh compatibility? Plus you have to make sure all the slashes, quotes, brackets and braces match. Vs --jp foo=$FOO --jp bar="baz-${BAR:-default-bar}" --jp date="\"$(date)\"" (I'm iffy on the last one, but it's WAY easier than trying to build that into an object)
- zimpenfish 5y ago> --jp date="\"$(date)\"" If it's going to properly crib `jo` syntax, you can just do `date="$(date)"` - no need for the second set of quotes (and, indeed, they'll mess it up.) > jo date="$(date)" {"date":"Thu 20 Jan 2022 20:59:16 GMT"} > jo date="\"$(date)\"" {"date":"\"Thu 20 Jan 2022 21:00:28 GMT\""}
- jbverschoor 5y ago--jp doesn't even make sense as it's an abbreviation.. it's rather be --json-part. The notation seems to be similar to HAML<>HTML. It's not JSON, and it doesn't make any sense other than really short ad hoc queries. It's just confusing and only solves a problem that a tiiiny amount of people have (regualar ad hoc json queries, where people are too lazy to actually write out json). Otherwise, why not do the same for XML, css. Or heck.. why not simply support HAML as well It's better to have such functionality extracted in some other tool and just pipe it
- deleted 5y ago[deleted]
- pluc 5y agohttps://curl.se/mail/archive-2022-01/0043.html https://curl.se/mail/archive-2022-01/0043.html
- fra 5y agoIf this means I can just use libcurl to GET a web endpoint and parse the JSON in a C program rather than have to manage multiple dependencies, I'm all for it!
- softwarebeware 5y agoI feel like jq already cornered the market on this. I'm unlikely to go back and update my scripts to use curl
- softwarebeware 5y agoI think this idea violates the Unix Philosophy. What should happen is that a separate utility could be used to pipe in the request body to cURL similar to https://stackoverflow.com/questions/12583930/use-pipe-for-curl-data https://stackoverflow.com/questions/12583930/use-pipe-for-cu...
- deleted 5y ago[deleted]
- pixl97 5y agoUnix philosophy is dead. It's body was crucified on the systemd cross.
- deleted 5y ago[deleted]
- pphysch 5y agoI know systemdphobia is cool, but AWK predates systemd by 3 decades (and the Unix philosophy by 1 year!). Needless to say, the industry found powerful tools like AWK (and SystemD) more useful than rigid dogmas.
- softwarebeware 5y agoAWK was designed by Kernighan who is on the record as subscribing to the Unix Philosophy. For all I know Aho and Weinberger also subscribe to the philosophy. I think its safe to say that AWK and the Unix Philosophy are compatible. I have never seen anything that says otherwise. Was "rigid dogmas" in reference to the Unix Philosophy? I haven't ever seen it described that way.
- pphysch 5y agoMy most readily available `man awk` spit out 1235 lines of text. Its namesake physical book is even longer. It is a Turing-complete language. It can execute arbitrary system commands with `system()`. It is the antithesis of the Unix Philosophy. Always has been. And that's okay.
- smrtinsert 5y agoPlease no, I'm thinking of me having to deal with someones 800 line curl script in the future. Agreed this doesn't feel very unixy.
- fhd2 5y agoThem adding some conditional logic next doesn't seem like that much of a stretch now! If it wasn't for this kind of stuff, there probably wouldn't be as many jobs in IT as there are.
- willcipriano 5y agoI imagine this will be part of libcurl? If so that makes it a one stop shop for JSON REST programming in C.
- adolph 5y agoI use cURL a lot. I can see how this would maybe somewhat useful for working very quickly, but the wiki-given use cases of k-v pairs and lists are simple enough in raw JSON. Something that would be helpful is for cURL, HTTPie, Postman, Fiddler, etc to standardize on a request/response pair format such as Chrome's HAR. There are some tools in NPM and the below HAR to cURL too, so I think native HAR support would be more helpful than a JSON builder. https://mattcg.github.io/har-to-curl/ https://mattcg.github.io/har-to-curl/
- datavirtue 5y agoI just want to pass it a filename that contains the JSON. Never been a fan of heaving around post bodies that dangle from a curl command...and I hate postman.
- jdc0589 5y agoThis would provide some additional utility, but honestly I don't see the point. Anyone sending JSON via curl CLI a lot is probably having to manipulate JSON via CLI for purposes other than sending requests with curl as well. It makes more sense for most people to just learn one json manipulation tool and pipe input in and out of things that need it.
- bborud 5y agoI wish curl had CoAP support
- wmanley 5y agoIt seems the goal is to make it easier to craft JSON by having curl perform escaping, while the proposal would seem to require some sort of in-memory tree representation of the data. One alternative would be to provide escaping more directly like this: curl --json '{ "map": %s, "prime": [ %i, %i ], "target": { "x": %i, "y": %i } }' "$continent" "$p1" "$p2" "$x" "$y" https://example.com And then curl would do the substitution with the appropriate type-specific escaping for each variable. This has a few nice properties: 1. What's on the command line resembles what's actually going to be sent. 2. Curl doesn't actually need to parse (nor validate) the JSON, or to create a tree representation of the data within itself. %s is invalid JSON anyway, so you can do a string substitution - all you need to keep track of are matching quotes (including escape sequences). I've used a printf style format string here, which could be expanded for extra convenience. For example the Python-style `%(env_var)s` sequences could be used which could expand environment variables directly. Or something could be added for convenient handling of bash arrays.
- syspec 5y agoDoesn't really look like it's adding anything, and the `jp` part looks like the people referenced on stackoverflow will just be more confused. Often times the JSON being sent down is complex, I can't imagine anyone wanting to basically rewrite it into something else for anything other than 2 field JSON objects
- axiosgunnar 5y agoBtw, did you notice how quickly the page loaded?
- pkrumins 5y agoSo great! This has been one of the most requested curl features for years. Without this feature, to send JSON, you had to craft a valid JSON string yourself or shell out to another utility that creates a valid JSON string.
- throwaddzuzxd 5y agoI've included --json in a custom redefinition for years, glad to see something like that coming to the official binary! curl() { args=() for arg in "$@"; do case $arg in --json) args+=("-H" "Content-Type: application/json") ;; *) args+=("$arg") ;; esac done command curl "${args[@]}" }